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

Francois Ozog francois.ozog at linaro.org
Thu Mar 16 19:09:53 CET 2017


On 16 March 2017 at 11:32, Chas Williams <3chas3 at gmail.com> wrote:
>
> 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.
>

SR-IOV is a way to partition hardware and is virtual from the PCI bus
stand point. Nothing to do with Qemu virtualization.
So acccessing a VF from either host or guest does not change the
nature of the device: it is a physical device with its features,
packet queue format, packet descriptors. You just change the access
method.
There is not such a thing as a VF driver. There are  XYZ model ABC PF
and VF PMDs. In other words, with SR-IOV you cannot use Intel 82599 VF
driver on a Mellanox Connectx4 NIC.


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




-- 
François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog


More information about the dev mailing list