From: Jakub Kicinski <kuba@kernel.org>
To: Pavan Chebbi <pavan.chebbi@broadcom.com>
Cc: Thomas Walsh <thwalsh@redhat.com>,
Michael Chan <michael.chan@broadcom.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Michal Schmidt <mschmidt@redhat.com>
Subject: Re: [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check
Date: Thu, 20 Aug 2026 10:39:50 -0700 [thread overview]
Message-ID: <20260820103950.5dfa2969@kernel.org> (raw)
In-Reply-To: <CALs4sv1zb7OemFcKRceoO49F8yPSOdZWSkomvU=mGmReR74=BA@mail.gmail.com>
On Wed, 19 Aug 2026 15:18:49 +0530 Pavan Chebbi wrote:
> > /* Enable TPH support as part of IRQ request */
> > - rc = pcie_enable_tph(bp->pdev, PCI_TPH_ST_IV_MODE);
> > - if (!rc)
> > - bp->tph_mode = PCI_TPH_ST_IV_MODE;
> > + if (BNXT_SUPPORTS_QUEUE_API(bp)) {
>
> IMO we should not gate pcie_enable_tph() on BNXT_SUPPORTS_QUEUE_API,
> since TPH's initial steering-tag placement is valid on its own and
> re-steering may never be needed in some cases?
> So in these cases it simply disables the feature.
Since irqs are requested at open wouldn't this mean that users who
program affinity (all serious users?) will have the wrong TPH? Which
is presumably worse than no TPH at all?
IMHO the simplicity and consistency is good. AFAIU queue API is
supported on fairly old bnxt NICs so the combination of CPU needing
TPH and NIC design being 15(?) years old is rather unlikely in the
first place. The real scenario where users may run into no queue API
support is FW being old, in which case FW should be updated?
next prev parent reply other threads:[~2026-08-20 17:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 14:15 [PATCH net] bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check Thomas Walsh
2026-08-19 9:48 ` Pavan Chebbi
2026-08-20 17:39 ` Jakub Kicinski [this message]
2026-08-20 17:55 ` Thomas Walsh
2026-08-20 18:15 ` Jakub Kicinski
2026-08-20 18:29 ` Thomas Walsh
2026-08-20 18:59 ` Michael Chan
2026-08-20 19:16 ` Michael Chan
2026-08-20 21:14 ` Jakub Kicinski
2026-08-20 21:24 ` Thomas Walsh
2026-08-20 19:11 ` Jakub Kicinski
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=20260820103950.5dfa2969@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=thwalsh@redhat.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