netdev - Re: Best way to reduce system call overhead for tun device I/O?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 4 Apr 2016 16:40:19 +0200
From:	Guus Sliepen <guus@...c-vpn.org>
To:	Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	David Miller <davem@...emloft.net>,
	Tom Herbert <tom@...bertland.com>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: Best way to reduce system call overhead for tun device I/O?

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@...workplumber.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@...c-vpn.org>