All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Michael Chan <michael.chan@broadcom.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
	pabeni@redhat.com, pavan.chebbi@broadcom.com,
	andrew.gospodarek@broadcom.com
Subject: Re: [PATCH] bnxt_en: Fix RSS logic in __bnxt_reserve_rings()
Date: Wed, 24 Jul 2024 17:25:36 -0700	[thread overview]
Message-ID: <20240724172536.318fb6f8@kernel.org> (raw)
In-Reply-To: <20240724222106.147744-1-michael.chan@broadcom.com>

On Wed, 24 Jul 2024 15:21:06 -0700 Michael Chan wrote:
> Now, with RSS contexts support, if the user has added or deleted RSS
> contexts, we may now enter this path to reserve the new number of VNICs.
> However, netif_is_rxfh_configured() will not return the correct state if
> we are still in the middle of set_rxfh().  So the existing code may
> set the indirection table of the default RSS context to default by
> mistake.

I feel like my explanation was more clear :S

The key point is that ethtool::set_rxfh() calls the "reload" functions
and expects the scope of the "reload" to be quite narrow, because only
the RSS table has changed. Unfortunately the add / delete of additional
contexts de-sync the resource counts, so ethtool::set_rxfh() now ends
up "reloading" more than it intended. The "more than intended" includes
going down the RSS indir reset path, which calls netif_is_rxfh_configured().
Return value from netif_is_rxfh_configured() during ethtool::set_rxfh()
is undefined.

Reported tag would have been nice too..

  reply	other threads:[~2024-07-25  0:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24 22:21 [PATCH] bnxt_en: Fix RSS logic in __bnxt_reserve_rings() Michael Chan
2024-07-25  0:25 ` Jakub Kicinski [this message]
2024-07-25 18:19   ` Jakub Kicinski
2024-07-25 21:33     ` Andy Gospodarek
2024-07-25 22:32       ` Jakub Kicinski
2024-07-26  6:23         ` Pavan Chebbi
2024-07-25 23:30 ` patchwork-bot+netdevbpf

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=20240724172536.318fb6f8@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew.gospodarek@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.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.