Re: [dpdk-dev] Beyond DPDK 2.0

[Luke Gorrie <luke@snabb.co>]

On 8 May 2015 at 06:16, Wiles, Keith <keith.wiles@intel.com> wrote:

> The PMDs or drivers would not be useful without DPDK MBUFS IMO
>

Surprisingly perhaps, I would find them very useful.

To me there are two parts to a driver: the hardware setup and the
transmit/receive.

The hardware setup is complex and generic. You have to read a thousand-page
data sheet and then write code to initialize the hardware, setup queues,
enable promisc/multicast, enable features you want like vmdq or flow
director, and so on. You need to accumulate workarounds for hard-to-test
problems like cards being discovered with unsuitable values in their
EEPROM. There is not much intellectual value in this code being written
more than once.

I would like to see this hardware setup code shared between many projects.
That code does not depend on a specific mbuf struct. Sharing could be done
with an embeddable PMD library, with a bifurcated driver in the kernel,
with the SR-IOV PF/VF model, or surely other ways too. These all have
limited applicability today.

The transmit/receive part, on the other hand, seems very
application-dependent. This part depends on the specific mbuf struct and
the way you are developing your application around it. You will need to
write code to suit your design for using scatter/gather, allowed sizes of
individual buffers, the granularity at which you are keeping track of
checksum validity, how you use TSO/LRO, how you use interrupts, how you
batch work together, and so on. This is easy or hard depending on how
simple or complex the application is.

I am not so interested in sharing this code. I think that different
applications will legitimately have different designs - including mbuf
structs - and they all need code that suits their own design. I think there
is a lot of value in people being creative in these areas and trying
different things.

So while Avi might only mean that he wants to allocate the bytes for his
mbufs himself, on our side we want to design our own mbuf struct. The cost
of that today is to write our own device drivers from scratch but for now
that seems justified. Going forward if there were a simpler mechanism that
reduced our workload and gave us access to more hardware - libixgbe,
libi40e, etc - that would be extremely interesting to us.

I suppose that another background question is whether the DPDK community
are chiefly concerned with advancing DPDK as a platform and a brand or are
broadly keen to develop and share code that is useful in diverse networking
projects. (Is this whole discussion off-topic for dpdk-devel?)

This is one of the many reasons why I would love to use parts of DPDK but
do not want to use all of it. (We also allocate our HugeTLBs differently,
etc, because we have different priorities.)