From: Guus Sliepen <guus@tinc-vpn•org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail•com>
Cc: Stephen Hemminger <stephen@networkplumber•org>,
David Miller <davem@davemloft•net>,
Tom Herbert <tom@herbertland•com>,
Network Development <netdev@vger•kernel.org>
Subject: Re: Best way to reduce system call overhead for tun device I/O?
Date: Mon, 4 Apr 2016 16:40:19 +0200 [thread overview]
Message-ID: <20160404144019.GN3771@sliepen.org> (raw)
In-Reply-To: <CAF=yD-LUaxsJMZiGXQdEDh-6UE11ApL89rjt=13oLK3FM1rerQ@mail.gmail.com>
On Sun, Apr 03, 2016 at 07:03:09PM -0400, Willem de Bruijn wrote:
> On Thu, Mar 31, 2016 at 7:39 PM, Stephen Hemminger <stephen@networkplumber•org> wrote:
>
> > Rather than bodge AF_PACKET onto TUN, why not just create a new device type
> > and control it from something modern like netlink.
Do we really want to introduce a whole new device type? The tun device
is working perfectly fine, except for the fact that there is no way to
send/receive multiple packets in one go.
> Depending on the use-case, it may be sufficient to extend AF_PACKET
> with limited tap functionality:
>
> - add a po->xmit mode that reinjects into the kernel receive path,
> analogous to pktgen's M_NETIF_RECEIVE mode.
>
> - optionally drop packets in __netif_receive_skb_core and xmit_one
> if any of the registered packet sockets accepted the packet and has
> a new intercept feature flag enabled.
>
> This can be applied to a dummy device, but much more interesting
> is to interpose on the flow of a normal nic. It is clearly not a drop-in
> replacement for a tap (let alone tun) device. I have some preliminary
> code.
It's not really tinc's use case, but I did try using socket(AF_PACKET)
bound to a tun interface, just to see if sendmmsg()/recvmmsg() works
then. It does, but indeed for packets that are sent to the socket, they
need to be reinjected into the kernel receive path. So I'll be happy to
test out your preliminary code.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@tinc-vpn•org>
next prev parent reply other threads:[~2016-04-04 14:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 22:40 Best way to reduce system call overhead for tun device I/O? Guus Sliepen
2016-03-31 21:18 ` Tom Herbert
2016-03-31 21:20 ` David Miller
2016-03-31 22:28 ` Guus Sliepen
2016-03-31 23:39 ` Stephen Hemminger
2016-04-03 23:03 ` Willem de Bruijn
2016-04-04 14:40 ` Guus Sliepen [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-04-04 13:35 ValdikSS
2016-04-04 17:28 ` Stephen Hemminger
[not found] <57026C8F.8050406@valdikss.org.ru>
2016-04-04 14:31 ` Guus Sliepen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160404144019.GN3771@sliepen.org \
--to=guus@tinc-vpn$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)org \
--cc=tom@herbertland$(echo .)com \
--cc=willemdebruijn.kernel@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox