[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <748c0685-cd16-4f7e-b359-91b095fc3d26@intel.com>
Date: Mon, 4 Nov 2024 13:56:20 +0100
From: Mateusz Polchlopek <mateusz.polchlopek@...el.com>
To: Simon Horman <horms@...nel.org>
CC: <intel-wired-lan@...ts.osuosl.org>, <david.m.ertman@...el.com>,
<netdev@...r.kernel.org>, Przemek Kitszel <przemyslaw.kitszel@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net] ice: change q_index variable
type to s16 to store -1 value
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@...el.com>
>> Signed-off-by: Mateusz Polchlopek <mateusz.polchlopek@...el.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@...nel.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.
Mateusz
Powered by blists - more mailing lists