All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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 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.