[dpdk-dev] SIMD Rx/Tx paths

[Chen, Jing D]

> 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)?

I also agree auto-selection on tx/rx func. User needn't worry about how PMD to 
satisfy its' requirement, result is more important. 
Besides that, we should do more work in rx/tx configuration to help PMD better
decide the best rx/tx. Pkt_type is a good example. 
A possible way is to expose all possible PMD offload features into structure 
rte_eth_rxmode and rte_eth_txmode or a new structure.