From: Kohei Enju <enjuk@amazon.com>
To: <enjuk@amazon.com>
Cc: <aleksandr.loktionov@intel.com>, <andrew+netdev@lunn.ch>,
<anthony.l.nguyen@intel.com>, <davem@davemloft.net>,
<edumazet@google.com>, <intel-wired-lan@lists.osuosl.org>,
<kohei.enju@gmail.com>, <kuba@kernel.org>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>,
<przemyslaw.kitszel@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3] ixgbe: preserve RSS indirection table across admin down/up
Date: Wed, 3 Sep 2025 06:16:39 +0900 [thread overview]
Message-ID: <20250902211640.85359-1-enjuk@amazon.com> (raw)
In-Reply-To: <20250902210447.77961-2-enjuk@amazon.com>
On Wed, 3 Sep 2025 06:04:43 +0900, Kohei Enju wrote:
>On Tue, 2 Sep 2025 13:25:56 +0000, Loktionov, Aleksandr wrote:
>
>> [...]
>>> -
>>> - for (i = 0, j = 0; i < reta_entries; i++, j++) {
>>> - if (j == rss_i)
>>> - j = 0;
>>> + /* Update redirection table in memory on first init, queue
>>> count change,
>>> + * or reta entries change, otherwise preserve user
>>> configurations. Then
>>> + * always write to hardware.
>>> + */
>>> + if (adapter->last_rss_indices != rss_i ||
>>> + adapter->last_reta_entries != reta_entries) {
>>> + for (i = 0; i < reta_entries; i++)
>>> + adapter->rss_indir_tbl[i] = i % rss_i;
>>Are you sure rss_i never ever can be a 0?
>>This is the only thing I'm worrying about.
>
>Oops, you're exactly right. Good catch!
>
>I see the original code assigns 0 to rss_indir_tbl[i] when rss_i is 0,
>like:
> adapter->rss_indir_tbl[i] = 0;
Ahh, that's not true, my brain was not working... Sorry for messing up.
Anyway, in a situation where rss_i == 0, we should handle it somehow to
avoid zero-divisor.
>
>To handle this with keeping the behavior when rss_i == 0, I'm
>considering
>Option 1:
> adapter->rss_indir_tbl[i] = rss_i ? i % rss_i : 0;
>
>Option 2:
> if (rss_i)
> for (i = 0; i < reta_entries; i++)
> adapter->rss_indir_tbl[i] = i % rss_i;
> else
> memset(adapter->rss_indir_tbl, 0, reta_entries);
>
>Since this is not in the data path, the overhead of checking rss_i in
>each iteration might be acceptable. Therefore I'd like to adopt the
>option 1 for simplicity.
>
>Do you have any preference or other suggestions?
next prev parent reply other threads:[~2025-09-02 21:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 12:11 [PATCH iwl-next v3] ixgbe: preserve RSS indirection table across admin down/up Kohei Enju
2025-09-02 13:25 ` [Intel-wired-lan] " Loktionov, Aleksandr
2025-09-02 21:04 ` Kohei Enju
2025-09-02 21:04 ` Kohei Enju
2025-09-02 21:16 ` Kohei Enju [this message]
2025-09-03 6:21 ` Loktionov, Aleksandr
2025-09-05 8:53 ` Przemek Kitszel
2025-09-06 3:35 ` Kohei Enju
2025-09-06 3:22 ` Kohei Enju
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=20250902211640.85359-1-enjuk@amazon.com \
--to=enjuk@amazon.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kohei.enju@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox