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