[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240701201215.5b68e164@kernel.org>
Date: Mon, 1 Jul 2024 20:12:15 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Geetha sowjanya <gakula@...vell.com>
Cc: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<davem@...emloft.net>, <pabeni@...hat.com>, <edumazet@...gle.com>,
<sgoutham@...vell.com>, <sbhatta@...vell.com>, <hkelam@...vell.com>
Subject: Re: [net-next PATCH v7 00/10] Introduce RVU representors
On Fri, 28 Jun 2024 19:05:07 +0530 Geetha sowjanya wrote:
> This series adds representor support for each rvu devices.
> When switchdev mode is enabled, representor netdev is registered
> for each rvu device. In implementation of representor model,
> one NIX HW LF with multiple SQ and RQ is reserved, where each
> RQ and SQ of the LF are mapped to a representor. A loopback channel
> is reserved to support packet path between representors and VFs.
> CN10K silicon supports 2 types of MACs, RPM and SDP. This
> patch set adds representor support for both RPM and SDP MAC
> interfaces.
>
> - Patch 1: Refactors and exports the shared service functions.
> - Patch 2: Implements basic representor driver.
> - Patch 3: Add devlink support to create representor netdevs that
> can be used to manage VFs.
> - Patch 4: Implements basec netdev_ndo_ops.
> - Patch 5: Installs tcam rules to route packets between representor and
> VFs.
> - Patch 6: Enables fetching VF stats via representor interface
> - Patch 7: Adds support to sync link state between representors and VFs .
> - Patch 8: Enables configuring VF MTU via representor netdevs.
> - Patch 9: Add representors for sdp MAC.
> - Patch 10: Add devlink port support.
>
> Command to create VF representor
> #devlink dev eswitch set pci/0002:1c:00.0 mode switchdev
> VF representors are created for each VF when switch mode is set switchdev on representor PCI device
> # devlink dev eswitch set pci/0002:1c:00.0 mode switchdev
> # ip link show
> 25: r0p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 32:0f:0f:f0:60:f1 brd ff:ff:ff:ff:ff:ff
> 26: r1p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> link/ether 3e:5d:9a:4d:e7:7b brd ff:ff:ff:ff:ff:ff
>
> #devlink dev
> pci/0002:01:00.0
> pci/0002:02:00.0
> pci/0002:03:00.0
> pci/0002:04:00.0
> pci/0002:05:00.0
> pci/0002:06:00.0
> pci/0002:07:00.0
>
> ~# devlink port
> pci/0002:1c:00.0/0: type eth netdev r0p1v0 flavour pcipf controller 0 pfnum 1 vfnum 0 external false splittable false
> pci/0002:1c:00.0/1: type eth netdev r1p1v1 flavour pcivf controller 0 pfnum 1 vfnum 1 external false splittable false
> pci/0002:1c:00.0/2: type eth netdev r2p1v2 flavour pcivf controller 0 pfnum 1 vfnum 2 external false splittable false
> pci/0002:1c:00.0/3: type eth netdev r3p1v3 flavour pcivf controller 0 pfnum 1 vfnum 3 external false splittable false
Please document the state before and after switching modes, and record
this information in
Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
In the commands above you seem to operate on a pci/0002:1c:00.0 devlink
instance, and yet devlink dev does not list it. You have 2 netdevs,
8 devlinks, 4 ports, and no PF instance. It does not add up..
Powered by blists - more mailing lists