[quagga-dev 10950] Re: high-bandwidth, low-latency quagga necessary ?
Jose Gavine Cueto
pepedocs at gmail.com
Thu Dec 5 02:36:36 GMT 2013
""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?"
One could create an api or abstraction (portability issue agian) for the
poll-mode APIs where applications could interface or use the provided kni
whichever is better. Sadly, support for non-Intel drivers is not yet
as dump packet switch,
I believe this is a good start to see what some quick performance gains.
There are also APIs that provide l3 algorithms and take advantage of DPDK
I've seen netmap but I haven't used it. I have not seen any mention the
capability to take advantage of per core memory (e.g. NUMA).
On Wed, Dec 4, 2013 at 9:20 PM, Alexis Rosen <
quagga-users at alexis.users.panix.com> wrote:
> [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
> 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/
To stop learning is like to stop loving.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Quagga-dev