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:02:49 -0700 [thread overview]
Message-ID: <20260608190249.03f4d6e7@kernel.org> (raw)
In-Reply-To: <aidvzJEXmeS6Wuz7@rkannoth-OptiPlex-7090>
On Tue, 9 Jun 2026 07:13:40 +0530 Ratheesh Kannoth wrote:
> On 2026-06-09 at 04:10:14, Jakub Kicinski (kuba@kernel.org) wrote:
> > On Fri, 5 Jun 2026 12:02:37 +0530 Ratheesh Kannoth wrote:
> > > There is only one admin-function PCI device per system.
> > > Reject any additional AF probe with -EBUSY so the driver model matches
> > > hardware and automated reviewers can rely on a single bound instance.
> >
> > Could you point me to a PCI networking driver written in the last two
> > decades which would have this sort of limitation?
> >
> > At the very least you need to explain in the commit message **why**
> > correctly handling multiple devices in a system is beyond your
> > abilities.
>
> 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?
next prev parent reply other threads:[~2026-06-09 2:02 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 [this message]
2026-06-09 2:26 ` Ratheesh Kannoth
2026-06-09 2:41 ` Jakub Kicinski
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=20260608190249.03f4d6e7@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.