[dpdk-dev] Beyond DPDK 2.0

[Bruce Richardson]

On Fri, May 08, 2015 at 07:29:39AM +0200, Luke Gorrie wrote:
> On 8 May 2015 at 06:16, Wiles, Keith <keith.wiles at 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.

For the Intel NIC drivers, the hardware setup part used in DPDK is based off
the other Intel drivers for other OS's. The code you are interested in should
therefore be contained within the subfolders off each individual PMD. As you point
out below, the mbuf specific part is only present in the files in the top-level
PMD folder with the DPDK-specific RX/TX and queue setup routines.

Regards,
/Bruce

> 
> 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.)