[dpdk-dev] SIMD Rx/Tx paths

Ferruh Yigit ferruh.yigit at intel.com
Mon May 15 15:36:21 CEST 2017


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

> 
> /Bruce
> 



More information about the dev mailing list