All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Sreedevi Joshi <sreedevi.joshi@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	Erik Gabriel Carrillo <erik.g.carrillo@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH v2 iwl-net 2/2] idpf: fix issue with ethtool -n command display
Date: Wed, 1 Oct 2025 16:44:08 +0100	[thread overview]
Message-ID: <aN1MSIO27C24q-gL@horms.kernel.org> (raw)
In-Reply-To: <20250930212352.2263907-3-sreedevi.joshi@intel.com>

On Tue, Sep 30, 2025 at 04:23:52PM -0500, Sreedevi Joshi wrote:
> From: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> 
> When ethtool -n is executed on an interface to display the flow steering
> rules, "rxclass: Unknown flow type" error is generated.
> 
> The flow steering list maintained in the driver currently stores only the
> location and q_index but other fields of the ethtool_rx_flow_spec are not
> stored. This may be enough for the virtchnl command to delete the entry.
> However, when the ethtool -n command is used to query the flow steering
> rules, the ethtool_rx_flow_spec returned is not complete causing the
> error below.
> 
> Resolve this by storing the flow spec (fsp) when rules are added and
> returning the complete flow spec when rules are queried.
> 
> Also, change the return value from EINVAL to ENOENT when flow steering
> entry is not found during query by location or when deleting an entry.
> 
> Add logic to detect and reject duplicate filter entries at the same
> location and change logic to perform upfront validation of all error
> conditions before adding flow rules through virtchnl. This avoids the
> need for additional virtchnl delete messages when subsequent operations
> fail, which was missing in the original upstream code.
> 
> Example:
> Before the fix:
> ethtool -n eth1
> 2 RX rings available
> Total 2 rules
> 
> rxclass: Unknown flow type
> rxclass: Unknown flow type
> 
> After the fix:
> ethtool -n eth1
> 2 RX rings available
> Total 2 rules
> 
> Filter: 0
>         Rule Type: TCP over IPv4
>         Src IP addr: 10.0.0.1 mask: 0.0.0.0
>         Dest IP addr: 0.0.0.0 mask: 255.255.255.255
>         TOS: 0x0 mask: 0xff
>         Src port: 0 mask: 0xffff
>         Dest port: 0 mask: 0xffff
>         Action: Direct to queue 0
> 
> Filter: 1
>         Rule Type: UDP over IPv4
>         Src IP addr: 10.0.0.1 mask: 0.0.0.0
>         Dest IP addr: 0.0.0.0 mask: 255.255.255.255
>         TOS: 0x0 mask: 0xff
>         Src port: 0 mask: 0xffff
>         Dest port: 0 mask: 0xffff
>         Action: Direct to queue 0
> 
> Fixes: ada3e24b84a0 ("idpf: add flow steering support")
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> Co-developed-by: Sreedevi Joshi <sreedevi.joshi@intel.com>
> Signed-off-by: Sreedevi Joshi <sreedevi.joshi@intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>


WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Sreedevi Joshi <sreedevi.joshi@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	Erik Gabriel Carrillo <erik.g.carrillo@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Subject: Re: [PATCH v2 iwl-net 2/2] idpf: fix issue with ethtool -n command display
Date: Wed, 1 Oct 2025 16:44:08 +0100	[thread overview]
Message-ID: <aN1MSIO27C24q-gL@horms.kernel.org> (raw)
In-Reply-To: <20250930212352.2263907-3-sreedevi.joshi@intel.com>

On Tue, Sep 30, 2025 at 04:23:52PM -0500, Sreedevi Joshi wrote:
> From: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> 
> When ethtool -n is executed on an interface to display the flow steering
> rules, "rxclass: Unknown flow type" error is generated.
> 
> The flow steering list maintained in the driver currently stores only the
> location and q_index but other fields of the ethtool_rx_flow_spec are not
> stored. This may be enough for the virtchnl command to delete the entry.
> However, when the ethtool -n command is used to query the flow steering
> rules, the ethtool_rx_flow_spec returned is not complete causing the
> error below.
> 
> Resolve this by storing the flow spec (fsp) when rules are added and
> returning the complete flow spec when rules are queried.
> 
> Also, change the return value from EINVAL to ENOENT when flow steering
> entry is not found during query by location or when deleting an entry.
> 
> Add logic to detect and reject duplicate filter entries at the same
> location and change logic to perform upfront validation of all error
> conditions before adding flow rules through virtchnl. This avoids the
> need for additional virtchnl delete messages when subsequent operations
> fail, which was missing in the original upstream code.
> 
> Example:
> Before the fix:
> ethtool -n eth1
> 2 RX rings available
> Total 2 rules
> 
> rxclass: Unknown flow type
> rxclass: Unknown flow type
> 
> After the fix:
> ethtool -n eth1
> 2 RX rings available
> Total 2 rules
> 
> Filter: 0
>         Rule Type: TCP over IPv4
>         Src IP addr: 10.0.0.1 mask: 0.0.0.0
>         Dest IP addr: 0.0.0.0 mask: 255.255.255.255
>         TOS: 0x0 mask: 0xff
>         Src port: 0 mask: 0xffff
>         Dest port: 0 mask: 0xffff
>         Action: Direct to queue 0
> 
> Filter: 1
>         Rule Type: UDP over IPv4
>         Src IP addr: 10.0.0.1 mask: 0.0.0.0
>         Dest IP addr: 0.0.0.0 mask: 255.255.255.255
>         TOS: 0x0 mask: 0xff
>         Src port: 0 mask: 0xffff
>         Dest port: 0 mask: 0xffff
>         Action: Direct to queue 0
> 
> Fixes: ada3e24b84a0 ("idpf: add flow steering support")
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> Co-developed-by: Sreedevi Joshi <sreedevi.joshi@intel.com>
> Signed-off-by: Sreedevi Joshi <sreedevi.joshi@intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>


  reply	other threads:[~2025-10-01 15:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-30 21:23 [Intel-wired-lan] [PATCH v2 iwl-net 0/2] idpf: fix flow steering issues Sreedevi Joshi
2025-09-30 21:23 ` Sreedevi Joshi
2025-09-30 21:23 ` [Intel-wired-lan] [PATCH v2 iwl-net 1/2] idpf: fix memory leak of flow steer list on rmmod Sreedevi Joshi
2025-09-30 21:23   ` Sreedevi Joshi
2025-10-01 15:43   ` [Intel-wired-lan] " Simon Horman
2025-10-01 15:43     ` Simon Horman
2025-12-18  0:56     ` [Intel-wired-lan] " Mina Almasry via Intel-wired-lan
2025-12-18  0:56       ` Mina Almasry
2025-09-30 21:23 ` [Intel-wired-lan] [PATCH v2 iwl-net 2/2] idpf: fix issue with ethtool -n command display Sreedevi Joshi
2025-09-30 21:23   ` Sreedevi Joshi
2025-10-01 15:44   ` Simon Horman [this message]
2025-10-01 15:44     ` Simon Horman
2025-12-18  0:52     ` [Intel-wired-lan] " Mina Almasry via Intel-wired-lan
2025-12-18  0:52       ` Mina Almasry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aN1MSIO27C24q-gL@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=aleksandr.loktionov@intel.com \
    --cc=erik.g.carrillo@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=sreedevi.joshi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.