[dpdk-dev] Beyond DPDK 2.0

Wiles, Keith keith.wiles at intel.com
Fri May 8 16:44:17 CEST 2015


Hi Luke,

On 5/7/15, 10:29 PM, "Luke Gorrie" <luke at snabb.co> 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.
>
>
>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.

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

I would suggested you are correct DPDK as platform is more how it started
and is going, but it does not mean we can not move is a slightly different
direction to help other access the parts which are more generic.

Regards,
++Keith
>
>
>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.)
>
>
>
>
>
>
>



More information about the dev mailing list