2017-03-17 03:28, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > > 2017-02-23 13:27, Qi Zhang: > > > static void > > > +i40evf_dev_stats_reset(struct rte_eth_dev *dev) { > > > + struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data- > > >dev_private); > > > + /* only DPDK PF support this */ > > > + if (vf->version_major == I40E_DPDK_VERSION_MAJOR) { > > > + if (i40evf_reset_statistics(dev)) > > > + PMD_DRV_LOG(ERR, "Reset statistics failed"); > > > + } > > > +} > > > > One more SR-IOV feature not supported with a Linux PF. > > The basic stats feature must be marked as partially supported in > > doc/guides/nics/features/i40e_vf.ini > > See also this email: > > http://dpdk.org/ml/archives/dev/2017-March/060063.html > > > > I wonder whether we should allow such divergence between PF > > implementations. Intel committed to avoid such fragmentation and keep the > > SR-IOV messaging standard but it does not happen. > > It is said that we must allow fast innovation in DPDK space. > > I agree but we should also target a good usability of the VF drivers, > > allowing to > > replace the PF implementations as needed. > > Hi Thomas > > I think I need to clarify a little bit here. > I think we will try our best, but I don't think we can commit. As they are on > totally different community, and of cause code repositories. > > > > > Here is my suggestion: let's accept a VF feature only if the PF support is > > submitted to both dpdk.org and kernel.org mailing lists. > > I ask to add this topic to the next techboard meeting. > > Sorry, technically I disagree with this suggestion, as I don't understand why! > I was told DPDK is not Linux, and Linux is not DPDK. Why we want to add this > dependency on Linux PF host driver? And why just on PF/VF driver feature only? > I think if we can have any good innovative idea on DPDK first, why not just > have it on DPDK? Then Linux or even other OS/community/Company can learn > from DPDK and develop their own.
It is really a general problem. Here you are adding a feature in a VF driver. But it does not work with some PF drivers. We have the same problem when adding a feature which does not work on BSD or on a CPU architecture. Generally speaking, we have a usability issue when a feature works only with a given environment. And it is worst in the SR-IOV case because a VM can migrate from an hypervisor (with a given PF) to another (and different) one.
