On Tue, Sep 22, 2020 at 08:31:15AM -0400, Laine Stump wrote: > On 8/28/20 6:53 AM, Dmytro Linkin wrote: > >Current virPCIGetNetName() logic is to get net device name by checking > >it's phys_port_id, if caller provide it, or by it's index (eg, by it's > >position at sysfs net directory). This approach worked fine up until > >linux kernel version 5.8, where NVIDIA Mellanox driver implemented > >linking of VFs' representors to PCI device in switchdev mode. This mean > >that device's sysfs net directory will hold multiple net devices. Ex.: > > > >$ ls '/sys/bus/pci/devices/0000:82:00.0/net' > >ens1f0 eth0 eth1 > > > >Most switch devices support phys_port_name instead of phys_port_id, so > >virPCIGetNetName() will try to get PF name by it's index - 0. The > >problem here is that the PF nedev entry may not be the first. > > > >To fix that, for switch devices, we introduce a new logic to select the > >PF uplink netdev according to the content of phys_port_name. Extend > >virPCIGetNetName() with physPortNameRegex variable to get proper device > >by it's phys_port_name scheme, for ex., "p[0-9]+$" to get PF, > >"pf[0-9]+vf[0-9]+$" to get VF or "p1$" to get exact net device. So now > >virPCIGetNetName() logic work in following sequence: > > - filter by phys_port_id, if it's provided, > > or > > - filter by phys_port_name, if it's regex provided, > > or > > - get net device by it's index (position) in sysfs net directory. > >Also, make getting content of iface sysfs files more generic. > > > >Signed-off-by: Dmytro Linkin <dlinkin@xxxxxxxxxx> > >Reviewed-by: Adrian Chiris <adrianc@xxxxxxxxxx> > > > [...] > > > > > >+/* Represents format of PF's phys_port_name in switchdev mode: > >+ * 'p%u' or 'p%us%u'. New line checked since value is readed from sysfs file. > >+ */ > >+# define VIR_PF_PHYS_PORT_NAME_REGEX ((char *)"(p[0-9]+$)|(p[0-9]+s[0-9]+$)") > >+ > > > I've come back to look at this patch several times since it was > posted (sorry for the extreme delay in responding), but just can't > figure out what it's doing with this regex and why the regex is > necessary. Not having access to the hardware that it works with is a > bit of a problem, but perhaps I could get a better idea if you gave > a full example of sysfs contents? My concern with using a regex is > that it might work just fine when using one method for net device > naming, but break if that was changed. Also, it seems > counterintuitive that it would be necessary to look for a device > with a name matching a specific pattern; why isn't there simply a > single symbolic link somewhere in the sysfs tree for the net device > that just directly points at its physical port? That would be so > much simpler and more reliable (or at least it would give the > *perception* of being more reliable). > I'll emphasize that regex is being used for phys_port_name, NOT net device name (they are not the same). Anyway, I'll give an example. Lets look how virPCIGetNetName() currently work. At first it try to read phys_port_id of every net device in net folder, like: $ cd '/sys/bus/pci/devices/0000:80:02.0/0000:82:00.0/' $ cat net/ens1f0/phys_port_id Imagine we have single pci dual port nic (I hope named it right), eg. net folder holds net devices for both ports, so read operation will be successfull and function will return name of first or second port. For single port or dual pci nics (or for drivers which didn't implemented phys_port_id) read fails and function fallback to picking up device by it's index, which not really fine (I'll describe it later) but work 'cause net folder usualy contains only one net device. But kernel patch brought third case which not work. Here are ifaces of ConnectX-5 NIC: $ ls -l /sys/class/net | cut -d ' ' -f 9- ens1f0 -> ../../devices/pci0000:80/0000:80:02.0/0000:82:00.0/net/ens1f0 ens1f1 -> ../../devices/pci0000:80/0000:80:02.0/0000:82:00.1/net/ens1f1 ens1f2 -> ../../devices/pci0000:80/0000:80:02.0/0000:82:00.2/net/ens1f2 ens1f3 -> ../../devices/pci0000:80/0000:80:02.0/0000:82:00.3/net/ens1f3 ens1f0_0 -> ../../devices/pci0000:80/0000:80:02.0/0000:82:00.0/net/ens1f0_0 ens1f0_1 -> ../../devices/pci0000:80/0000:80:02.0/0000:82:00.0/net/ens1f0_1 ens1f0 & ens1f1 - PFs; ens1f2 & ens1f3 - VFs created on 1st PF and.. ens1f0_0 & ens1f0_1 - corresponding representors. Here is content of PFs' pci net folders (for comparison): $ ls '/sys/bus/pci/devices/0000:80:02.0/0000:82:00.0/net' ens1f0 ens1f0_0 ens1f0_1 $ ls '/sys/bus/pci/devices/0000:80:02.0/0000:82:00.1/net' ens1f1 When virPCIGetNetName() called for 2nd PF, for ex., which is in legacy mode, phys_port_id read fails (Operation not supported), function falling back to index and return name of first and only net device. Fine here. When function called for 1st PF in switchdev mode, sequence is the same and first net device name is returned. The problem here is that PF could be not the first device, because order is not persistent and defined by system. So approach is to find PF by reading phys_port_name. Ex.: $ cd '/sys/bus/pci/devices/0000:80:02.0/0000:82:00.0/net/' $ cat ens1f0/phys_port_name p0 $ cat ens1f0_0/phys_port_name pf0vf0 $ cat ens1f0_1/phys_port_name pf0vf1 And here regex is used. We really don't care about exact value of phys_port_name, 'cause there only one PF net device. And regex also cover smart nics, which use other phys_port_name scheme. So, WDYT?
