[dpdk-dev] [PATCH v4 00/17] Wind River Systems AVP PMD vs virtio?

Chas Williams 3chas3 at gmail.com
Thu Mar 16 11:32:37 CET 2017


On Thu, 2017-03-16 at 03:18 +0000, O'Driscoll, Tim wrote:
> > From: Vincent JARDIN [mailto:vincent.jardin at 6wind.com]
> > 
> > Le 15/03/2017 à 11:55, Thomas Monjalon a écrit :
> > >> I'd suggest that this is a good topic for the next Tech Board
> > meeting.
> > > I agree Tim.
> > > CC'ing techboard to add this item to the agenda of the next meeting.
> > 
> > Frankly, I disagree, it is missing some discussions on the list.
> 
> I think the discussion on the mailing list is at an impasse and it won't be resolved there. I think the Tech Board needs to consider several issues:
> - What are the requirements for a new PMD to be accepted? For example, you're asking for performance data in this case, when this hasn't been a requirement for other PMDs.

It does seem like that would be the purpose of the tech board in the
first place.  The tech board doesn't need to decide individual matters
but must at least provide guidelines for the developers to follow.
Otherwise you are asking for a popular vote to decide matters.

As for performance data, the tech board could certainly make this a
requirement.  If your argument is that we can't require X because we
didn't require X in the past means that the tech board is basically
pointless -- it can't make any changes to the existing processes.

Should performance be a criterion?  Possibly.  What happens when X
is faster at B but slower at A and Y is faster at A but slower at B?
Now you don't have a clear case of what "performance" means since it
varies based on what the end user is doing.  So which is faster?

DPDK already has overlapping PMD's -- PCAP, AF_PACKET and now TAP.
So if your reasoning is that DPDK doesn't want overlapping support,
DPDK needs to start thinking about narrowing down the existing
overlapping PMD's.  Otherwise, it does look like hypocrisy.

> - Should there be different requirements for PMDs for virtual devices versus physical devices?

How "real" does a device need to be?  SRIOV blurs the line somewhat
between virtual and physical devices.  What is a VF, physical or virtual?
It looks like a physical device in DPDK, but it's really virtual.

Personally, I would prefer to see a minimum set of required capabilities.
Not every driver needs to support offload but it seems like there should
be some minimum set of functionality, like changing the MTU, supporting
tagged traffic, or changing the MAC address.  Stuff a driver might need
to be able to interoperate with other parts of DPDK (like bonding).

> - Based on these criteria, should the AVP PMD be accepted or not?


More information about the dev mailing list