From: Paolo Abeni <pabeni@redhat.com>
To: "Badole, Vishal" <vishal.badole@amd.com>,
Jacob Keller <jacob.e.keller@intel.com>,
Shyam-sundar.S-k@amd.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
Thomas.Lendacky@amd.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Raju.Rangoju@amd.com
Subject: Re: [PATCH net V2] amd-xgbe: Fix to ensure dependent features are toggled with RX checksum offload
Date: Thu, 24 Apr 2025 10:54:07 +0200 [thread overview]
Message-ID: <d5114fb3-4ca8-4ab8-acb2-120a7b940d6f@redhat.com> (raw)
In-Reply-To: <c1d1ce25-8b5f-4638-bcd3-0d96c3139fd7@amd.com>
On 4/23/25 9:57 AM, Badole, Vishal wrote:
> On 4/23/2025 3:50 AM, Jacob Keller wrote:
>> On 4/21/2025 7:04 AM, Vishal Badole wrote:
>>> According to the XGMAC specification, enabling features such as Layer 3
>>> and Layer 4 Packet Filtering, Split Header, Receive Side Scaling (RSS),
>>> and Virtualized Network support automatically selects the IPC Full
>>> Checksum Offload Engine on the receive side.
>>>
>>> When RX checksum offload is disabled, these dependent features must also
>>> be disabled to prevent abnormal behavior caused by mismatched feature
>>> dependencies.
>>>
>>> Ensure that toggling RX checksum offload (disabling or enabling) properly
>>> disables or enables all dependent features, maintaining consistent and
>>> expected behavior in the network device.
>>>
>>
>> My understanding based on previous changes I've made to Intel drivers,
>> the netdev community opinion here is that the driver shouldn't
>> automatically change user configuration like this. Instead, it should
>> reject requests to disable a feature if that isn't possible due to the
>> other requirements.
>>
>> In this case, that means checking and rejecting disable of Rx checksum
>> offload whenever the features which depend on it are enabled, and reject
>> requests to enable the features when Rx checksum is disabled.
>
> Thank you for sharing your perspective and experience with Intel
> drivers. From my understanding, the fix_features() callback in ethtool
> handles enabling and disabling the dependent features required for the
> requested feature to function correctly. It also ensures that the
> correct status is reflected in ethtool and notifies the user.
>
> However, if the user wishes to enable or disable those dependent
> features again, they can do so using the appropriate ethtool settings.
AFAICS there are two different things here:
- automatic update of NETIF_F_RXHASH according to NETIF_F_RXCSUM value:
that should be avoid and instead incompatible changes should be rejected
with a suitable error message.
- automatic update of header split and vxlan depending on NETIF_F_RXCSUM
value: that could be allowed as AFAICS the driver does not currently
offer any other method to flip modify configuration (and make the state
consistent).
Thanks,
Paolo
next prev parent reply other threads:[~2025-04-24 8:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 14:04 Vishal Badole
2025-04-22 22:20 ` Jacob Keller
2025-04-23 7:57 ` Badole, Vishal
2025-04-24 8:54 ` Paolo Abeni [this message]
2025-04-24 12:56 ` Badole, Vishal
2025-04-24 15:29 ` Keller, Jacob E
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=d5114fb3-4ca8-4ab8-acb2-120a7b940d6f@redhat.com \
--to=pabeni@redhat.com \
--cc=Raju.Rangoju@amd.com \
--cc=Shyam-sundar.S-k@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=vishal.badole@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®