[dpdk-dev] SIMD Rx/Tx paths

[Shahaf Shuler]

Monday, May 15, 2017 5:26 PM, Thomas Monjalon:
> 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)?

This work might help for this [1].
The application will specify on device configuration which Tx and Rx offloads it needs. 
Knowing that each feature request might affect the performance, the application is expected to choose the most limited set of offloads. 
The PMD, will then choose accordingly the best data path function which supports all of those offloads, knowing the rest will never be used.

[1] http://dpdk.org/ml/archives/dev/2017-May/065077.html