On 9/17/2020 9:41 PM, Parav Pandit wrote:
Hi David,
From: David Ahern <dsah...@gmail.com>
Sent: Friday, September 18, 2020 9:08 AM
On 9/17/20 9:29 PM, Parav Pandit wrote:
Examples:
Create a PCI PF and PCI SF port.
$ devlink port add netdevsim/netdevsim10/10 flavour pcipf pfnum 0 $
devlink port add netdevsim/netdevsim10/11 flavour pcisf pfnum 0
sfnum
44 $ devlink port show netdevsim/netdevsim10/11
netdevsim/netdevsim10/11: type eth netdev eni10npf0sf44 flavour
pcisf
controller 0 pfnum 0 sfnum 44 external true splittable false
function:
hw_addr 00:00:00:00:00:00 state inactive
$ devlink port function set netdevsim/netdevsim10/11 hw_addr
00:11:22:33:44:55 state active
$ devlink port show netdevsim/netdevsim10/11 -jp {
"port": {
"netdevsim/netdevsim10/11": {
"type": "eth",
"netdev": "eni10npf0sf44",
I could be missing something, but it does not seem like this patch
creates the netdevice for the subfunction.
The sf port created here is the eswitch port with a valid switch id similar to
PF
and physical port.
So the netdev created is the representor netdevice.
It is created uniformly for subfunction and pf port flavours.
To be clear: If I run the devlink commands to create a sub-function, `ip link
show` should list a net_device that corresponds to the sub-function?
In this series only representor netdevice corresponds to sub-function will be
visible in ip link show, i.e. eni10npf0sf44.
This should be OK if the eSwitch mode is changed to switchdev.
But i think it should be possible to create a subfunction even in legacy
mode where representor netdev is not created.
Netdevsim is only simulating the eswitch side or control path at present for
pf/vf/sf ports.
So other end of this port (netdevice/rdma device/vdpa device) are not yet
created.
Subfunction will be anchored on virtbus described in RFC [1], which is not yet
in-kernel yet.
Grep for "every SF a device is created on virtbus" to jump to this part of the
long RFC.
[1] https://lore.kernel.org/netdev/20200519092258.GF4655@nanopsycho/
