From: Jacob Keller <jacob.e.keller@intel.com>
To: Vishal Badole <Vishal.Badole@amd.com>, <Shyam-sundar.S-k@amd.com>,
<andrew+netdev@lunn.ch>, <davem@davemloft.net>,
<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
<Thomas.Lendacky@amd.com>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: <stable@vger.kernel.org>
Subject: Re: [PATCH net V2] amd-xgbe: Fix to ensure dependent features are toggled with RX checksum offload
Date: Tue, 22 Apr 2025 15:20:20 -0700 [thread overview]
Message-ID: <d0902829-c588-4fba-93c0-9c0dfcc221f6@intel.com> (raw)
In-Reply-To: <20250421140438.2751080-1-Vishal.Badole@amd.com>
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.
next prev parent reply other threads:[~2025-04-22 22:20 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 [this message]
2025-04-23 7:57 ` Badole, Vishal
2025-04-24 8:54 ` Paolo Abeni
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=d0902829-c588-4fba-93c0-9c0dfcc221f6@intel.com \
--to=jacob.e.keller@intel.com \
--cc=Shyam-sundar.S-k@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=Vishal.Badole@amd.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
/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®