Using netmap with tun/tap adapter

[SviMik]

First question: is it possible to create a virtual adapter with netmap to do the same thing as tun/tap adapter does to replace the obviously slow tun.ko driver completely?

Second question: is it a good idea to use netmap on existing tun/tap adapter? I have tried pkt-gen with previously created tap0, and it seems to work well in both directions. But since I can't see any patches for tun.c, I suspect the 'generic' driver being used. Will it work correctly with tun and tap? Have anyone tried to do that? And most interesting, why the patch is missing? Is it already fast enough with 'generic' driver and simply no patch is required? Or the was no interest in this subject?

[vmaffione]

2017-09-05 18:12 GMT-07:00 SviMik notifications@github.com:

First question: is it possible to create a virtual adapter with netmap to do the same thing as tun/tap adapter does to replace the obviously slow tun.ko driver completely?

The real question is what you want to do with a tunneling software interface.

Tun/Tap allows an user-space application to inject/intercept IP/Ethernet packets to/from the kernel network stack. Netmap is an user-space API, so you can already do that by definition, whatever the netmap port is (physical port, VALE port, pipe, monitor, etc.).

Second question: is it a good idea to use netmap on existing tun/tap adapter? I have tried pkt-gen with previously created tap0, and it seems to work well in both directions. But since I can't see any patches for tun.c, I suspect the 'generic' driver being used. Will it work correctly with tun and tap? Have anyone tried to do that? And most interesting, why the patch is missing? Is it already fast enough with 'generic' driver and simply no patch is required? Or the was no interest in this subject?

The only reason I see to use netmap on a tap interface is to interact with legacy software that uses tap interfaces. Netmap works correctly on tap, using the generic driver, correct. I don't think patching the driver is worth the effort, because it cannot benefit from batching too much (apart amortizing the locking cost for the skb queues internal to the tap). tun won't work with netmap, because it's not an Ethernet interface, but and IP interface.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/luigirizzo/netmap/issues/360, or mute the thread https://github.com/notifications/unsubscribe-auth/AEsSwR0Xu_vzCzLjDbqULDm7JxCoEmyyks5sffF4gaJpZM4PNtsW .

-- Vincenzo Maffione

[SviMik]

The real question is what you want to do with a tunneling software interface.

There's a certain VPN server that use tun and tap adapters. The problem with tun.ko is lacking a way to read or write multiple packets at once, which results in many system calls (one call per packet, basically). I want to upgrade this piece of software to use netmap for interacting with tap adapter. It's not about intercepting packets in existing adapter, because L2 VPN tunnel (which VPN with tap is) is about exposing a new virtual network adapter to the system like if it was a physical adapter connected somewhere.

tun won't work with netmap, because it's not an Ethernet interface, but and IP interface

Too bad. Is there that big difference? Because VPN software handles them almost identically, that I started to think the difference is only the presence of MAC header.

[polachok]

You may be in IFF_MULTI_QUEUE (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/tuntap.txt?id=HEAD#n108)

[SviMik]

As I understand, IFF_MULTI_QUEUE does not help to reduce CPU load, only to load more cores if you have them.

[vmaffione]

You can modify your VPN server to read/write from/to a netmap port instead of the TUN/TAP. But if you are using TAP/TUN is probably because you have socket applications on the same host, that use the TUN/TAP as network interface. But this means that you are already operating using the legacy socket networking, i.e. a system call per packet, so that the bottleneck is probably going to be there (and not in the VPN server reading from a netmap port).

The TUN/TAP difference is probably not a big deal, you can probably make up a fake ethernet header for netmap to use.

[SviMik]

But if you are using TAP/TUN is probably because you have socket applications on the same host, that use the TUN/TAP as network interface.

I need the host stack to NAT the traffic going from TAP. I doubt there is some NAT router for netmap (correct me if I'm wrong), and writing an efficient NAT router with SNAT+DNAT functionality from scratch... well, it would be fun thing to do, but I really doubt I can beat iptables in performance.

As for the second statement, since NAT is done by kernel, there is no userland-socket-application that could be a bottleneck. So what I need is just to feed packets to the TAP interface efficiently, so the host stack could take them, do NAT and forward to another interface.

[vmaffione]

The host rings (of whatever interface, TAP included) are exactly what you need to inject/intercept packets between host stack and user-space application. If your applications transmit 100 packets on the host TX ring of ethX, 100 packets will pop up in the kernel as they were received from ethX. If kernel transmits 100 packets to ethX, your application will find 100 packets in the host RX ring.

System calls are not the only bottleneck. Nor "userspace applications" are bottlenecks in principle. The point of netmap (like DPDK and others) is to avoid using skbuffs, dynamic allocations and packet copies and also batch system calls (but the latter is only one among the four points). If you mix traditional kernel-space processing (iptables) and netmap, it's unlikely that you can benefit from netmap, since you are still using skbuffs, dynamic allocations and packet copies. To benefit from netmap/DPDK you should use only netmap/DPDK for all the stages of your packet processing pipeline, so that you can do true zerocopy and true I/O batching along all your pipeline. You could take a look at netmap-ipfw if you are looking for firewall functionalities.

2017-09-06 12:10 GMT-07:00 SviMik notifications@github.com:

But if you are using TAP/TUN is probably because you have socket applications on the same host, that use the TUN/TAP as network interface.

I need the host stack to NAT the traffic going from TAP. I doubt there is some NAT router for netmap (correct me if I'm wrong), and writing an efficient NAT router with SNAT+DNAT functionality from scratch... well, it would be fun thing to do, but I really doubt I can beat iptables in performance.

As for the second statement, since NAT is done by kernel, there is no userland-socket-application that could be a bottleneck. So what I need is just to feed packets to the TAP interface efficiently, so the host stack could take them, do NAT and forward to another interface.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/luigirizzo/netmap/issues/360#issuecomment-327584300, or mute the thread https://github.com/notifications/unsubscribe-auth/AEsSwduIjUemvBN4zwthalwnjwX-JETUks5sfu4PgaJpZM4PNtsW .

-- Vincenzo Maffione