While working on ice VF Live Migration support, I noticed some oddities
with how the vsi->max_frame and vsi->rx_buf_len fields are used.
Technically, both the hardware and virtchnl interface allow a VF to set
per-queue maximum frame size and buffer lengths. The existing code does
this in a surprising and non-intuitive way by setting the VSI variables for
each VF queue in between programming the queues during bring-up.
I ran into this when accidentally assuming that the max_frame variable was
constant for a given VF VSI, and not per-queue.
Instead of keeping the per-VSI values, replace them with per-ring values.
We already have rx_buf_len for the hotpath, so we can just add max_frame.
Better yet, the structure has gaps, so we're not wasting any additional
space.
This refactor simplifies the logic for programming the VF and removes the
surprise of overwriting the ring->rx_buf_len with the vsi->rx_buf_len when
programming.
While implementing this change, I also noticed that the ring accessed when
programming the Rx rings was sometimes indexed via the q_idx and sometimes
indexed by the 'i' iterator over the queue pair array. Nothing validated
that these two values are equivalent. It makes sense to only interact with
the ring via the q_idx so that we are consistent in the event that these
values differ.
Signed-off-by: Jacob Keller <jacob.e.kel...@intel.com>
---
Jacob Keller (2):
ice: consistently use q_idx in ice_vc_cfg_qs_msg()
ice: store max_frame and rx_buf_len only in ice_rx_ring
drivers/net/ethernet/intel/ice/ice.h | 3 ---
drivers/net/ethernet/intel/ice/ice_txrx.h | 3 ++-
drivers/net/ethernet/intel/ice/ice_base.c | 34 ++++++++++++++-------------
drivers/net/ethernet/intel/ice/ice_virtchnl.c | 26 ++++++++++----------
4 files changed, 32 insertions(+), 34 deletions(-)
---
base-commit: bfba7bc8b7c2c100b76edb3a646fdce256392129
change-id:
20240829-e810-live-migration-jk-per-queue-max-frame-rx-buf-len-d07c1a3b10d7
Best regards,
--
Jacob Keller <jacob.e.kel...@intel.com>
