[quagga-dev 10945] Re: high-bandwidth, low-latency quagga necessary ?

Alexis Rosen quagga-users at alexis.users.panix.com
Wed Dec 4 13:20:36 GMT 2013

[Sorry for the dup, I had the wrong address on this the fist time]

AFAICT none of this discussion is directly related to quagga code, but it's of extreme interest to a lot of quagga users (and devs too?) so for the moment, unless yelled at by the list owner, I'm going to continue this here.

On Dec 3, 2013, at 9:32 PM, Jose Gavine Cueto <pepedocs at gmail.com> wrote:
> The first thing that came up in my mind for improving quagga or any other networking application that uses the NIC, is to take advantage of DPDK's Poll-Mode drivers.  Basically it provides APIs that allows faster TX/RX (e.g. burst, polling, locality, pre-allocated buffers, etc.).  Packets could be pumped using dpdk upto layer 2 and sent to quagga for IP layer processing.  But of course, this is just an idea, I'm not sure if the performance gain will be significant or if it will exist.

First step would presumably be to simply figure out what's needed to make that driver work as a drop-in replacement for the existing drivers (presumably they have replacements for the e1000, igb, and ixgbe drivers, at least). Does that by itself improve the picture at all?

Beyond that, it's not clear to me how DPDK can help, except to extent that you modify the kernel to take advantage of it - in particular, the IP stack and netfilter. I suppose, if you simply want to act as a dumb packet switch (is that a common use case?), you could pull packets directly off the wire into userspace, select the route, and drop them right back onto the wire. You could also go halfway, leaving either send or receive as-is and just fiddling the other half, but then you're still copying the packet from kernel to user space (or vice-versa) which will likely lose more than anything you might gain.

For the dumb-packet-switch project, you'd probably have a small daemon acting as a routing engine, calling a library which would be equally useful for mz and similar. And you'd want to do it that way, because if you don't load-testing your code will be difficult (or expensive).

> As to using the kernel IP stack, I've not tried mixing DPDK with it since I've already used DPDK in L2 only.  Some organizations (I've learned) use DPDK to create their own optimized IP layers though I believe this isn't practical for quagga.  I saw this rump-tcpip IP stack which uses DPDK also, this could be used to replace the kernel IP stack, though it will surely require a lot of work.

Ultimately, I'm guessing that that's the way it goes... unless kernel devs jump into this with both feet and just modify the kernel to do what we're talking about. That seems unlikely given the portability problem.

Have you seen netmap? http://info.iet.unipi.it/~luigi/netmap/


More information about the Quagga-dev mailing list