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

[Thomas Monjalon <thomas@monjalon.net>]

15/05/2017 16:12, Richardson, Bruce:
> From: Yigit, Ferruh
> > 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

Please remember that there are different vector code paths
(SSE/AVX, NEON, Altivec).

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

I agree.
If we can be sure what the application needs, we can select the best code
path and mark the feature supported.
But can we be sure of the expectations for every features?
How do we know that the application relies on certain packet types
(which are not recognized by some code paths)?