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