[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+N7sc5bc4MP/woq@corigine.com>
Date: Wed, 8 Feb 2023 11:38:41 +0100
From: Simon Horman <simon.horman@...igine.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: David Miller <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>,
Michael Chan <michael.chan@...adcom.com>,
Andy Gospodarek <andy@...yhouse.net>,
Gal Pressman <gal@...dia.com>,
Saeed Mahameed <saeed@...nel.org>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Tony Nguyen <anthony.l.nguyen@...el.com>,
Edward Cree <ecree.xilinx@...il.com>,
Vladimir Oltean <vladimir.oltean@....com>,
Andrew Lunn <andrew@...n.ch>, Fei Qin <fei.qin@...igine.com>,
netdev@...r.kernel.org, oss-drivers@...igine.com
Subject: Re: [PATCH/RFC net-next 1/2] devlink: expose port function commands
to assign VFs to multiple netdevs
On Mon, Feb 06, 2023 at 06:42:27PM -0800, Jakub Kicinski wrote:
> On Mon, 6 Feb 2023 16:36:02 +0100 Simon Horman wrote:
> > +VF assignment setup
> > +---------------------------
> > +In some cases, NICs could have multiple physical ports per PF. Users can assign VFs to
> > +different ports.
>
> Please make sure you run make htmldocs when changing docs,
> this will warn.
Thanks, will do.
> > +- Get count of VFs assigned to physical port::
> > +
> > + $ devlink port show pci/0000:82:00.0/0
> > + pci/0000:82:00.0/0: type eth netdev enp130s0np0 flavour physical port 0 splittable true lanes 4
>
> Physical port has VFs? My knee jerk reaction is that allocating
> resources via devlink is fine but this seems to lean a bit into
> forwarding. How do other vendors do it? What's the mapping of VFs
> to ports?
We are not aware of any non-vendor-specific mechanism.
If there is one we'd gladly consider it.
> What do you suggest should happen when user enables switchdev mode?
Thanks for pointing this out. It ought to be documented.
Prior to this patch-set, for all NFP application firmwares supported by
upstream (and I'm not implying there is anything sneaky elsewhere - I am
honestly not aware of any such things), the embedded switch on the NIC
(which as you know is software running on the NIC), allows forwarding of
packets between VFs and physical ports without any partitioning - other
than what policy may implement.
This remains the behaviour if the feature proposed by this patch-set is not
enabled, either because it is unsupported by the application firmware, or
has not been enabled, i.e. using devlink.
If the feature is enabled, then in effect there is a partition between
VFs on one physical port and those on another. And some sort of forwarding
in software (on the host) is required. It is my understanding that
this is the dominant behaviour amongst multi-port NICs from other vendors
which, by default (and perhaps can only), associate VFs with specific
physical ports.
This is my understanding of things.
And I believe this applies in both switchdev and legacy mode.
Powered by blists - more mailing lists