From: Jakub Kicinski <kuba@kernel.org>
To: Ratheesh Kannoth <rkannoth@marvell.com>
Cc: <linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<andrew+netdev@lunn.ch>, <davem@davemloft.net>,
<donald.hunter@gmail.com>, <edumazet@google.com>,
<horms@kernel.org>, <jiri@resnulli.us>, <pabeni@redhat.com>,
<sgoutham@marvell.com>
Subject: Re: [PATCH v19 net-next 1/9] octeontx2-af: Enforce single RVU AF probe
Date: Mon, 8 Jun 2026 19:41:51 -0700 [thread overview]
Message-ID: <20260608194151.7535b2f7@kernel.org> (raw)
In-Reply-To: <aid55liiG7bcuZ3f@rkannoth-OptiPlex-7090>
On Tue, 9 Jun 2026 07:56:46 +0530 Ratheesh Kannoth wrote:
> > > The comparison to a generic PCI networking driver isn't quite applicable
> > > here. The RVU AF (Administrative Function) is not a standard NIC PF —
> > > it is a system-level resource manager that owns a single, shared set of
> > > AF registers across the entire RVU subsystem. The hardware spec is
> > > explicit on this: "RVU has a single, common set of AF registers.
> > >
> > > This is fundamentally different from a multi-port NIC where each PF is
> > > an independent, symmetric instance. In the RVU model, there is exactly
> > > one AF device per SoC, and all other PFs communicate with it
> > > via mailboxes rather than accessing AF registers directly. Allowing a
> > > second AF probe would mean two driver instances racing to manage the
> > > same global hardware state — provisioning LFs, configuring
> > > NPC/NIX/NPA — with no hardware arbitration between them.
> >
> > I asked you before - is this a driver for a PCIe devices?
> > You said "yes". If so what prevents the user from plugging two such
> > devices into one system?
>
> The RVU AF (PCI device ID 0xA065) is not a pluggable add-in card. It
> is an integrated function inside the Marvell OcteonTX2/CN10K/CN20K SoC.
> On-chip firmware programs the PCI configuration space for all RVU
> functions at boot time — setting device ID, class code, and BAR layout
> via RVU_PRIV_PF()_ID_CFG — and the Linux PCI subsystem then discovers
> what firmware has configured. There is no slot, no connector, and no
> mechanism by which a second instance of this device could appear on the
> same system. The hardware exposes exactly one AF PCI device per SoC,
> and that is the only device this driver (rvu af driver) binds to.
SMH, I asked you if it is a PCIe **card** or a SoC device.
You answered "This is PCIe." Now you're saying it's a function within
the SoC. I can see the driver is operating on struct pci_device...
Just say this is an integrated device within the SoC then in the commit
message.
next prev parent reply other threads:[~2026-06-09 2:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 6:32 [PATCH v19 net-next 0/9] octeontx2-af: npc: Enhancements Ratheesh Kannoth
2026-06-05 6:32 ` [PATCH v19 net-next 1/9] octeontx2-af: Enforce single RVU AF probe Ratheesh Kannoth
2026-06-08 2:17 ` Ratheesh Kannoth
2026-06-08 2:25 ` Ratheesh Kannoth
2026-06-08 22:40 ` Jakub Kicinski
2026-06-09 1:43 ` Ratheesh Kannoth
2026-06-09 2:02 ` Jakub Kicinski
2026-06-09 2:26 ` Ratheesh Kannoth
2026-06-09 2:41 ` Jakub Kicinski [this message]
2026-06-05 6:32 ` [PATCH v19 net-next 2/9] octeontx2-af: npc: cn20k: debugfs enhancements Ratheesh Kannoth
2026-06-08 2:20 ` Ratheesh Kannoth
2026-06-08 2:26 ` Ratheesh Kannoth
2026-06-05 6:32 ` [PATCH v19 net-next 3/9] devlink: heap-allocate param fill buffers in devlink_nl_param_fill Ratheesh Kannoth
2026-06-05 6:32 ` [PATCH v19 net-next 4/9] devlink: Implement devlink param multi attribute nested data values Ratheesh Kannoth
2026-06-05 6:32 ` [PATCH v19 net-next 5/9] octeontx2-af: npc: cn20k: add subbank search order control Ratheesh Kannoth
2026-06-08 2:22 ` Ratheesh Kannoth
2026-06-08 2:28 ` Ratheesh Kannoth
2026-06-05 6:32 ` [PATCH v19 net-next 6/9] octeontx2: cn20k: Coordinate default rules with NIX LF lifecycle Ratheesh Kannoth
2026-06-08 2:29 ` Ratheesh Kannoth
2026-06-05 6:32 ` [PATCH v19 net-next 7/9] octeontx2-af: npc: Support for custom KPU profile from filesystem Ratheesh Kannoth
2026-06-08 2:23 ` Ratheesh Kannoth
2026-06-08 2:30 ` Ratheesh Kannoth
2026-06-05 6:32 ` [PATCH v19 net-next 8/9] octeontx2: cn20k: Respect NPC MCAM X2/X4 profile in flows and DFT alloc Ratheesh Kannoth
2026-06-08 2:24 ` Ratheesh Kannoth
2026-06-08 2:31 ` Ratheesh Kannoth
2026-06-05 6:32 ` [PATCH v19 net-next 9/9] octeontx2-af: npc: cn20k: Allocate npc_priv and dstats dynamically Ratheesh Kannoth
2026-06-08 2:25 ` Ratheesh Kannoth
2026-06-08 2:32 ` Ratheesh Kannoth
-- strict thread matches above, loose matches on Subject: below --
2026-06-05 3:50 [PATCH v19 net-next 0/9] octeontx2-af: npc: Enhancements Ratheesh Kannoth
2026-06-05 3:50 ` [PATCH v19 net-next 1/9] octeontx2-af: Enforce single RVU AF probe Ratheesh Kannoth
2026-06-05 7:47 ` Ratheesh Kannoth
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=20260608194151.7535b2f7@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rkannoth@marvell.com \
--cc=sgoutham@marvell.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.