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

Charlet, Ricky ricky.charlet at hp.com
Mon Dec 9 17:24:32 GMT 2013


Howdy,
                I just wanted to contribute a word here too.

                Don't view DPDK as replacing the drivers, view DPDK as replacing the TCPIP stack (and drivers). But there is a trick... All communication that zebra has with the kernel, over ioctl or over netlink, stays the same and DPDK snoops it and just "does the right thing". The kernel interface is unmodified.

                So a system using DPDK should feel no different to zebra than a system using kernel mode TCP/IP stack. Zebra still makes calls and sends events to the kernel (add/del route) as before and zebra still hears about events from the kernel as before (link up/down). Forwarding packets flow through DPDK in a usermode stack now (and hopefully move faster) instead of moving through the kernel stack.

                For socket calls, like open/close/read/write, DPDK will either handle those with a modified socket api or leave those to the kernel as before, depending upon how you configure DPDK.  I suggest that quagga daemons, continue to operate on the assumption that people using DPDK in a router care about packet forwarding latency and not packet source/sync latency, and therefore quagga daemons (control plane) sockets are left to the kernel, not DPDK.

                If you agree with my reasoning, very close to *nothing* in quagga needs to be modified to adapt to a DPDK system. Well, why should I equivocate... OK... I claim that truly nothing in quagga need be modified to adapt to a DPDK system that leaves quagga daemon (control plane) sockets to the kernel.


--
Ricky Charlet
Software Dev / Routing Dude: Aries team, Roseville CA
ricky.charlet at hp.com<mailto:ricky.charlet at hp.com>
USA: 916.785.2090

From: Jose Gavine Cueto [mailto:pepedocs at gmail.com]
Sent: Thursday, December 05, 2013 6:10 PM
To: Alexis Rosen
Cc: quagga-dev at lists.quagga.net Dev
Subject: [quagga-dev 10953] Re: high-bandwidth, low-latency quagga necessary ?

"The DPDK site seems to imply that they include complete replacement drivers. My assumption was that those drivers, while perhaps providing additional APIs, also supported the APIs that the standard drivers provide. Is that wrong?"

Yes they provided complete replacements.  I'm not sure what you mean about the APIs that the standard drivers provide, but by experience the poll-mode drivers provided by DPDK is very flexible and could do what the kernel drivers can.

"Looks like Intel thought so too. See https://01.org/packet-processing/intel%C2%AE-ovdk - that job seems to be done already, and they're well on their way to a smart switch."

Correct.  I've been monitoring this and this is quite promising.  Though as for the moment, it is still very young and the last time I read about it was that the performance optimization is yet applicable only between VM to VM communication.

Cheers,
Pepe

On Thu, Dec 5, 2013 at 4:26 PM, Alexis Rosen <quagga-users at alexis.users.panix.com<mailto:quagga-users at alexis.users.panix.com>> wrote:
On Dec 4, 2013, at 9:36 PM, Jose Gavine Cueto <pepedocs at gmail.com<mailto:pepedocs at gmail.com>> wrote:
> 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 available.
The DPDK site seems to imply that they include complete replacement drivers. My assumption was that those drivers, while perhaps providing additional APIs, also supported the APIs that the standard drivers provide. Is that wrong?

> 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 features.
Looks like Intel thought so too. See https://01.org/packet-processing/intel%C2%AE-ovdk - that job seems to be done already, and they're well on their way to a smart switch.

> 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).
There is likely some facility for this, since they claim linear scalability across cores.

/a



--
To stop learning is like to stop loving.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20131209/c646cdd1/attachment-0001.html>


More information about the Quagga-dev mailing list