[dpdk-dev] SIMD Rx/Tx paths

Bruce Richardson bruce.richardson at intel.com
Mon May 15 15:15:17 CEST 2017


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


More information about the dev mailing list