> -----Original Message----- > From: Yigit, Ferruh > Sent: Monday, May 15, 2017 2:36 PM > To: Richardson, Bruce <bruce.richard...@intel.com>; Thomas Monjalon > <tho...@monjalon.net> > Cc: dev@dpdk.org; Yuanhan Liu <yuanhan....@linux.intel.com>; Maxime > Coquelin <maxime.coque...@redhat.com>; Chen, Jing D > <jing.d.c...@intel.com>; Zhang, Helin <helin.zh...@intel.com>; Wu, > Jingjing <jingjing...@intel.com>; Lu, Wenzhuo <wenzhuo...@intel.com>; > Ananyev, Konstantin <konstantin.anan...@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
