9eb60580 | 24-Jan-2025 |
Bruce Richardson <bruce.richardson@intel.com> |
net/intel: extract common Rx vector criteria
While some drivers have specific criteria for when a vector driver can be enabled on the Rx path, there are a number of basic criteria which apply across
net/intel: extract common Rx vector criteria
While some drivers have specific criteria for when a vector driver can be enabled on the Rx path, there are a number of basic criteria which apply across all drivers. Centralize those in the intel/common folder, and then update drivers to use the common conditional checks. This adds some additional restrictions to some drivers like ixgbe, where those conditions were necessary but never checked.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Praveen Shetty <praveen.shetty@intel.com>
show more ...
|
61dcf278 | 24-Jan-2025 |
Bruce Richardson <bruce.richardson@intel.com> |
net/intel: create common mbuf initializer
Across a number of drivers, the same code is used for initializing the "mbuf_initializer" value inside the rx queue structure for use with the vector driver
net/intel: create common mbuf initializer
Across a number of drivers, the same code is used for initializing the "mbuf_initializer" value inside the rx queue structure for use with the vector drivers. Since the rx queue structures are (currently) different across the drivers, we cannot just move a single copy of the function to a common location. Instead, we create a dedicated function which just creates the mbuf initializer for a particular port.
In creating this function, we can shorten it vs the original versions by initializing the mbuf fields as they are defined, rather than afterwards. We can also remove the use of the barrier and temporary uintptr_t variable, because the mbuf has been reworked so that rearm_data is a proper single-element array in a union.
Across ixgbe, i40e, iavf and i40e, we can call this function to initialize the rxq data, replacing the "*_rxq_vec_setup_default" functions. Only the i40e was slightly different, having an extra assignment in it, to set the "sse" flag (even in case of neon and altivec paths). This assignment was just duplicated to the calling sites for simplicity and to keep existing behaviour.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Praveen Shetty <praveen.shetty@intel.com>
show more ...
|
d3bb1c9e | 24-Jan-2025 |
Bruce Richardson <bruce.richardson@intel.com> |
net/intel: remove unneeded vector flags and cleanup code
With all drivers using the common Tx structure updated so that their vector paths all use the simplified Tx mbuf ring format, it's no longer
net/intel: remove unneeded vector flags and cleanup code
With all drivers using the common Tx structure updated so that their vector paths all use the simplified Tx mbuf ring format, it's no longer necessary to have a separate flag for the ring format and for use of a vector driver.
Remove the former flag and base all decisions off the vector flag. With that done, we go from having only two paths to consider for releasing all mbufs in the ring, not three. That allows further simplification of the "ci_txq_release_all_mbufs" function.
The separate function to free buffers from the vector driver not using the simplified ring format can similarly be removed as no longer necessary.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Praveen Shetty <praveen.shetty@intel.com>
show more ...
|
0f62bbef | 24-Jan-2025 |
Bruce Richardson <bruce.richardson@intel.com> |
net/iavf: use common Tx free for AVX-512
Switch the iavf driver to use the common Tx free function. This requires one additional parameter to that function, since iavf sometimes uses context descrip
net/iavf: use common Tx free for AVX-512
Switch the iavf driver to use the common Tx free function. This requires one additional parameter to that function, since iavf sometimes uses context descriptors which means that we have double the descriptors per SW ring slot.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Praveen Shetty <praveen.shetty@intel.com>
show more ...
|