On 16 March 2017 at 11:32, Chas Williams <3ch...@gmail.com> wrote: > > On Thu, 2017-03-16 at 03:18 +0000, O'Driscoll, Tim wrote: > > > From: Vincent JARDIN [mailto:vincent.jar...@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.o...@linaro.org | Skype: ffozog
