Re: [dpdk-dev] Beyond DPDK 2.0

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 8 May 2015 14:44:17 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:

> Hi Luke,
> 
> On 5/7/15, 10:29 PM, "Luke Gorrie" <luke@snabb.co> wrote:
> 
> >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 think I see your point about hardware setup and handling packets from
> the rings as it would be nice to allow others to utilize those parts of
> the code. The drivers (I believe) are mostly from FreeBSD and changed to
> be our PMDs, which to me they are fairly generic in some cases. I will
> have a look at the drivers when I get back home. In the past I have
> written drivers using the your suggestion around we have a upper and lower
> layer the lower layer is all hardware specific and the upper layer is all
> around the network stack interface. My point is we should be able to split
> the two and possible provide you the lower layer APIs in a cleaner way.

The point is this is BSD code, you can do with it what you will.
But the DPDK community doesn't have to care about changes breaking your
proprietary application.

That is the problem with the whole concept of making DPDK drivers
a separate component. It makes them immutable and unmaintainable.
Developers don't want to be responsible for code that is used outside
its original scope.