Re: [dpdk-dev] SIMD Rx/Tx paths

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Monday, May 15, 2017 2:36 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; Yuanhan Liu <yuanhan.liu@linux.intel.com>; Maxime
> Coquelin <maxime.coquelin@redhat.com>; Chen, Jing D
> <jing.d.chen@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Wu,
> Jingjing <jingjing.wu@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Subject: Re: SIMD Rx/Tx paths
> 
> On 5/15/2017 2:15 PM, Bruce Richardson wrote:
> > On Mon, May 15, 2017 at 02:35:55PM +0200, Thomas Monjalon wrote:
> >> Hi,
> >>
> >> I would like to open a discussion about SIMD code in drivers.
> >>
> >> I think we should not have different behaviours or features
> >> capabilities, in the different code paths of a same driver.
> >> I suggest to consider such differences as exceptions.
> >> So we should merge features files (i.e. matrix columns), and remove
> >> these files:
> >>
> >> % ls doc/guides/nics/features/*_vec.ini
> >>
> >> doc/guides/nics/features/fm10k_vec.ini
> >> doc/guides/nics/features/fm10k_vf_vec.ini
> >> doc/guides/nics/features/i40e_vec.ini
> >> doc/guides/nics/features/i40e_vf_vec.ini
> >> doc/guides/nics/features/ixgbe_vec.ini
> >> doc/guides/nics/features/ixgbe_vf_vec.ini
> >> doc/guides/nics/features/virtio_vec.ini
> >>
> >> If a feature is not supported in all code paths of a driver, it must
> >> be marked as partially (P) supported.
> >>
> >> Then the mid-term goal will be to try removing these inconsistencies.
> >>
> >> Opinions/comments?
> >
> > Yes, there are inconsistencies, but if they are hidden from the user,
> > e.g. by having the driver select automatically the most appropriate
> > path, I don't think we should need to mark the support as "partial".
> > Instead, it should be marked as being fully supported, but perhaps
> > with a note indicating that a performance hit may be experienced due
> > to the code taking a less-optimised driver path. After all, especially
> > in the TX code path, a lot of the speed-up comes from not supporting
> > different features, as well as from the vectorization. In those cases
> > "closing the gap" may mean losing performance for those who don't want
> > the features, which is not acceptable. Any feature support we can add,
> > without affecting performance, should of course be implemented.
> 
> I mostly agree with Bruce, except for PMD selection the patch
> automatically.
> 
> There is a trade off between feature set and performance, scalar driver
> favors features and vector driver favors performance, I think good to have
> both.
> 
> And I agree that feature support should be added to vector drivers as long
> as it doesn't effect the performance.
> 
> Related to the driver auto selecting the path, I concern this may confuse
> the user, because he may end up a situation he doesn't clear about
> supported features, I am for more explicit way to select the scalar or
> vector driver.
> 
> And for merging the features files, most of the items are already same for
> scalar and vector drivers, so perhaps we can merge files and use different
> syntax for features that is different for scalar and vector:
> Ys: Yes Scalar [no vector]
> Yv: Yes Vector [no scalar]
> Y: Yes Both
> Ps: Partially Scalar [no vector]
> Pv: Partially Vector [no scalar]
> P: Partially Both
> YsPv, YvPs
> 

For the table, I don't really mind so much what scheme is agreed. For the user doing the coding, while I can accept that it might be useful to support explicitly request a vector or scalar driver, I'd definitely prefer the default state to remain auto-selection based on features requested. If a user want TSO, then pick the best driver path that supports TSO, and don't force the user to read up on what the different paths are!

/Bruce