Re: [Intel-wired-lan] [PATCH iwl-net] ice: change q_index variable type to s16 to store -1 value

[Simon Horman <horms@kernel.org>]

On Mon, Nov 04, 2024 at 01:56:20PM +0100, Mateusz Polchlopek wrote:
> 
> 
> On 11/2/2024 3:38 PM, Simon Horman wrote:
> > On Mon, Oct 28, 2024 at 12:59:22PM -0400, Mateusz Polchlopek wrote:
> > > Fix Flow Director not allowing to re-map traffic to 0th queue when action
> > > is configured to drop (and vice versa).
> > > 
> > > The current implementation of ethtool callback in the ice driver forbids
> > > change Flow Director action from 0 to -1 and from -1 to 0 with an error,
> > > e.g:
> > > 
> > >   # ethtool -U eth2 flow-type tcp4 src-ip 1.1.1.1 loc 1 action 0
> > >   # ethtool -U eth2 flow-type tcp4 src-ip 1.1.1.1 loc 1 action -1
> > >   rmgr: Cannot insert RX class rule: Invalid argument
> > > 
> > > We set the value of `u16 q_index = 0` at the beginning of the function
> > > ice_set_fdir_input_set(). In case of "drop traffic" action (which is
> > > equal to -1 in ethtool) we store the 0 value. Later, when want to change
> > > traffic rule to redirect to queue with index 0 it returns an error
> > > caused by duplicate found.
> > > 
> > > Fix this behaviour by change of the type of field `q_index` from u16 to s16
> > > in `struct ice_fdir_fltr`. This allows to store -1 in the field in case
> > > of "drop traffic" action. What is more, change the variable type in the
> > > function ice_set_fdir_input_set() and assign at the beginning the new
> > > `#define ICE_FDIR_NO_QUEUE_IDX` which is -1. Later, if the action is set
> > > to another value (point specific queue index) the variable value is
> > > overwritten in the function.
> > > 
> > > Fixes: cac2a27cd9ab ("ice: Support IPv4 Flow Director filters")
> > > Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> > > Signed-off-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
> > 
> > This looks good, although I am interested to know what the maximum value
> > for q_index is. And, considering unsigned values are used elsewhere, if
> > using 0xffff within this driver was considered instead of -1.
> > 
> > That notwithstanding,
> > 
> > Reviewed-by: Simon Horman <horms@kernel.org>
> 
> Hi Simon!
> 
> Thanks for Your review.
> What is about q_index: it stores queue index which can be theoretically
> up to few thousands. So in this case s16 should be enough and will be
> able to hold all indexes. I didn't consider 0xffff as this may be
> misleading, I decided to stay with -1.

Thanks. I agree that if we are expecting the maximum (positive) value
to be a few thousand, then the s16-based approach you have taken is a good
one.