[systemd-devel] Proposal: Add biosdevname naming scheme to systemd
There are currently two competing naming mechanisms for network cards, biosdevname and systemd. Systemd currently has some limitations on naming cards that use network partitioning or support SR-IOV. Proposal is to add support for biosdevname-like names as part of systemd. The names would be created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could then be used in the udev rules scripts to replace the external biosdevname handler. At least on Dell systems, systemd generates unusable names (PCI B:D:F vs Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, but they do have a SMBIOS slot number. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Mon, 02.03.15 09:45, Jordan Hargrave (jhar...@gmail.com) wrote: > There are currently two competing naming mechanisms for network cards, > biosdevname and systemd. Systemd currently has some limitations on naming > cards that use network partitioning or support SR-IOV. Proposal is to add > support for biosdevname-like names as part of systemd. The names would be > created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could > then be used in the udev rules scripts to replace the external biosdevname > handler. No. We didn't adopt the biosdevname names in udev since they didn't actually deliver what they claimed to deliver, and resorted to naming things after probing order in the end. Use biosdevname if you want biosdevname names, it still works. Sorry, but this has no place in systemd/udev. We didn't adopt the names for a reason. > At least on Dell systems, systemd generates unusable names (PCI B:D:F vs > Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, > but they do have a SMBIOS slot number. "unusable"? Can you elaborate what you mean by that? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
Hi Jordan, On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave wrote: > There are currently two competing naming mechanisms for network cards, > biosdevname and systemd. Systemd currently has some limitations on naming > cards that use network partitioning or support SR-IOV. Could you point to an example so we can fix it? I thought all bug reports had been handled, but maybe I lost track of something. > Proposal is to add > support for biosdevname-like names as part of systemd. The names would be > created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could > then be used in the udev rules scripts to replace the external biosdevname > handler. I don't think this makes much sense. If biosdevname had been acceptable, the udev naming scheme would not have been introduced in the first place. > At least on Dell systems, systemd generates unusable names (PCI B:D:F vs > Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, > but they do have a SMBIOS slot number. Wouldn't the better approach be to simply add SMBIOS support to udev then? I must admit I don't know what challenges that entails, but seems like a natural first step. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: > Hi Jordan, > > On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave wrote: >> There are currently two competing naming mechanisms for network cards, >> biosdevname and systemd. Systemd currently has some limitations on naming >> cards that use network partitioning or support SR-IOV. > > Could you point to an example so we can fix it? I thought all bug > reports had been handled, but maybe I lost track of something. > I have a quad-port NIC: :40:00.0 = PCIE bridge (SMBIOS Slot 2) :41:00.0 = Ethernet Device (port1) :41:00.1 = Ethernet Device (port2) :42:00.0 = Ethernet Device (port3) :42:00.1 = Ethernet Device (port4) biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. With systemd, it's ugly. I added the patch to get SMBIOS slot numbers and I see systemd get RANDOM names depending on boot. Either: s2f0 (p1) s2f1 (p2) p66s0f0 (p3) p66s0f1 (p4) I also saw the opposite: p65s0f0 (p1) p65s0f1 (p2) s2f0 (p3) s2f1 (p4) Since systemd doesn't have a concept of a 'port', whichever devices get named first (they are named in parallel, race conditions), the other devices have name collision (function 0,1 are duplicate, but on different bus). >> Proposal is to add >> support for biosdevname-like names as part of systemd. The names would be >> created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could >> then be used in the udev rules scripts to replace the external biosdevname >> handler. > > I don't think this makes much sense. If biosdevname had been > acceptable, the udev naming scheme would not have been introduced in > the first place. > biosdevname is going away in new version of RHEL, so we will lose the capability to detect if two 'virtual' NICs are actually the same physical NIC. The naming in systemd doesn't have the capabilty of showing relationship between physical/virtual (SR-IOV) NIC location name. >> At least on Dell systems, systemd generates unusable names (PCI B:D:F vs >> Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, >> but they do have a SMBIOS slot number. > > Wouldn't the better approach be to simply add SMBIOS support to udev > then? I must admit I don't know what challenges that entails, but > seems like a natural first step. > That could be possible. I've tried submitting a patch upstream for kernel but hasn't been accepted yet. So SMBIOS parsing would have to be part of systemd. > Cheers, > > Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave wrote: > On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: >> Hi Jordan, >> >> On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave wrote: >>> There are currently two competing naming mechanisms for network cards, >>> biosdevname and systemd. Systemd currently has some limitations on naming >>> cards that use network partitioning or support SR-IOV. >> >> Could you point to an example so we can fix it? I thought all bug >> reports had been handled, but maybe I lost track of something. >> > > I have a quad-port NIC: > :40:00.0 = PCIE bridge (SMBIOS Slot 2) > :41:00.0 = Ethernet Device (port1) > :41:00.1 = Ethernet Device (port2) > :42:00.0 = Ethernet Device (port3) > :42:00.1 = Ethernet Device (port4) > > biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. > How does it determine that 41 and 42 are the same device? I.e. how does it differ from real bridge with two independent two-port cards behind? Could you explain what information it is using? Is it exported in sysfs? ... > > That could be possible. I've tried submitting a patch upstream for > kernel but hasn't been accepted yet. So SMBIOS parsing would have to > be part of systemd. > udev is already using SMBIOS type 41 to obtain slot number for on-board devices. As long as this information is exported via sysfs for other PCI cards it should be straightforward to extend. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Tue, Oct 20, 2015 at 6:46 AM, Jordan Hargrave wrote: > On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: >> Hi Jordan, >> >> On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave wrote: >>> There are currently two competing naming mechanisms for network cards, >>> biosdevname and systemd. Systemd currently has some limitations on naming >>> cards that use network partitioning or support SR-IOV. >> >> Could you point to an example so we can fix it? I thought all bug >> reports had been handled, but maybe I lost track of something. >> > > I have a quad-port NIC: > :40:00.0 = PCIE bridge (SMBIOS Slot 2) > :41:00.0 = Ethernet Device (port1) > :41:00.1 = Ethernet Device (port2) > :42:00.0 = Ethernet Device (port3) > :42:00.1 = Ethernet Device (port4) > > biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. > > With systemd, it's ugly. I added the patch to get SMBIOS slot numbers > and I see systemd get RANDOM names depending on boot. > > Either: > s2f0 (p1) > s2f1 (p2) > p66s0f0 (p3) > p66s0f1 (p4) > > I also saw the opposite: > p65s0f0 (p1) > p65s0f1 (p2) > s2f0 (p3) > s2f1 (p4) That looks like an issue with the PCI hotplug drivers. You either need to load them early enough, or not at all. Or just disable the slot naming policy in a networkd link file. > Since systemd doesn't have a concept of a 'port', whichever devices > get named first (they are named in parallel, race conditions), the > other devices have name collision (function 0,1 are duplicate, but on > different bus). Systemd cannot have a concept of a port across otherwise independent devices. It would mean to mainain a counter across devices which again will depend and introduce names based on enumeration order. >>> Proposal is to add >>> support for biosdevname-like names as part of systemd. The names would be >>> created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could >>> then be used in the udev rules scripts to replace the external biosdevname >>> handler. This is unlikely going to happen. Biosdevname "invents" counters which are unreliable and introduce inter-device probe-order depenedencies. It causes the same problem as the the kernel's ethX, just less likely. Systemd cannot do that. >> I don't think this makes much sense. If biosdevname had been >> acceptable, the udev naming scheme would not have been introduced in >> the first place. Right, the udev naming would not have been there or used the same names if biosdevname was reliable, which it unfortunately isn't for the above mentioned reasons, > biosdevname is going away in new version of RHEL, so we will lose the > capability to detect if two 'virtual' NICs are actually the same > physical NIC. The naming in systemd doesn't have the capabilty of > showing relationship between physical/virtual (SR-IOV) NIC location > name. > >>> At least on Dell systems, systemd generates unusable names (PCI B:D:F vs >>> Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, >>> but they do have a SMBIOS slot number. >> >> Wouldn't the better approach be to simply add SMBIOS support to udev >> then? I must admit I don't know what challenges that entails, but >> seems like a natural first step. > > That could be possible. I've tried submitting a patch upstream for > kernel but hasn't been accepted yet. So SMBIOS parsing would have to > be part of systemd. The kernel would need to export the parsed result of SMBIOS at the PCI device, which systemd can use. Systemd itself will unlikely parse SMBIODS directly. In any case, there can be no concept introduction of any cross-device counters though. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Tue, Oct 20, 2015 at 1:15 AM, Andrei Borzenkov wrote: > On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave wrote: >> On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: >>> Hi Jordan, >>> >>> On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave wrote: There are currently two competing naming mechanisms for network cards, biosdevname and systemd. Systemd currently has some limitations on naming cards that use network partitioning or support SR-IOV. >>> >>> Could you point to an example so we can fix it? I thought all bug >>> reports had been handled, but maybe I lost track of something. >>> >> >> I have a quad-port NIC: >> :40:00.0 = PCIE bridge (SMBIOS Slot 2) >> :41:00.0 = Ethernet Device (port1) >> :41:00.1 = Ethernet Device (port2) >> :42:00.0 = Ethernet Device (port3) >> :42:00.1 = Ethernet Device (port4) >> >> biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. >> > > How does it determine that 41 and 42 are the same device? I.e. how > does it differ from real bridge with two independent two-port cards > behind? Could you explain what information it is using? Is it exported > in sysfs? > > ... It knows they are on the same slot as the parent device has SMBIOS Slot#2 (Type 9). So all child devices of a physical slot are on the same card. I'm currently using a patch to systemd that reads SMBIOS type 9. There isn't a kernel sysfs variable that displays this. Systemd naming really is unfriendly to the end user..., something like p66s0f0 doesn't tell you at all where in the system the device is located. Even worse, as the p number is in decimal, where lspci is in hex. >> >> That could be possible. I've tried submitting a patch upstream for >> kernel but hasn't been accepted yet. So SMBIOS parsing would have to >> be part of systemd. >> > > udev is already using SMBIOS type 41 to obtain slot number for > on-board devices. As long as this information is exported via sysfs > for other PCI cards it should be straightforward to extend. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Tue, Oct 20, 2015 at 3:14 AM, Kay Sievers wrote: > On Tue, Oct 20, 2015 at 6:46 AM, Jordan Hargrave wrote: >> On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: >>> Hi Jordan, >>> >>> On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave wrote: There are currently two competing naming mechanisms for network cards, biosdevname and systemd. Systemd currently has some limitations on naming cards that use network partitioning or support SR-IOV. >>> >>> Could you point to an example so we can fix it? I thought all bug >>> reports had been handled, but maybe I lost track of something. >>> >> >> I have a quad-port NIC: >> :40:00.0 = PCIE bridge (SMBIOS Slot 2) >> :41:00.0 = Ethernet Device (port1) >> :41:00.1 = Ethernet Device (port2) >> :42:00.0 = Ethernet Device (port3) >> :42:00.1 = Ethernet Device (port4) >> >> biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. >> >> With systemd, it's ugly. I added the patch to get SMBIOS slot numbers >> and I see systemd get RANDOM names depending on boot. >> >> Either: >> s2f0 (p1) >> s2f1 (p2) >> p66s0f0 (p3) >> p66s0f1 (p4) >> >> I also saw the opposite: >> p65s0f0 (p1) >> p65s0f1 (p2) >> s2f0 (p3) >> s2f1 (p4) > > That looks like an issue with the PCI hotplug drivers. You either need > to load them early enough, or not at all. Or just disable the slot > naming policy in a networkd link file. > >> Since systemd doesn't have a concept of a 'port', whichever devices >> get named first (they are named in parallel, race conditions), the >> other devices have name collision (function 0,1 are duplicate, but on >> different bus). > > Systemd cannot have a concept of a port across otherwise independent > devices. It would mean to mainain a counter across devices which > again will depend and introduce names based on enumeration order. > Dell systems export a string as part of PCI VPD data that has a mapping of which PCI B:D:F belongs to which port. This mainly is used for mapping virtual/partition devices to the parent partition. These devices show up as physical pci devices on the pci scan. There are also cards that support virtual SR-IOV devices. The quad-port example above was a special case, but here is another. We have a Mellanox card that implements two network devices under a single B:D:F. It also supports SR-IOV. So a single PCI B:D:F maps to 16 network devices. Systemd uses the sysfs dev_port/dev_id to identify which actual device it is. Systemd names these as: p66s0f0 p66s0f0d1 p66s0f1 p66s0f1d1 p66s0f2 p66s0f2d1 p66s0f3 p66s0f3d1 p66s0f4 p66s0f4d1 etc. Again, p66 doesn't tell the user anything about where the device is in the system or which port the network cable is plugged into. biosdevname looks up the 'physical' sr-iov device and SMBIOS slot number and names them: p2p1 (original device) p2p1_0 (virtual) p2p1_1 p2p1_2 p2p1_3 ... p2p2 p2p2_0 (virtual device) p2p2_1 ... etc. This feature is really what we would like to see implemented in systemd. First, name devices properly based on SMBIOS slot number. Second, have physical name of NIC be the base name, along with virtual index. We use this when enabling bonding to warn if a bond is enabled using the same physical cable. The name can be stored in a separate environment variable (ID_NET_NAME_BIOSDEVNAME or similar). Proposal is to add support for biosdevname-like names as part of systemd. The names would be created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could then be used in the udev rules scripts to replace the external biosdevname handler. > > This is unlikely going to happen. Biosdevname "invents" counters which > are unreliable and introduce inter-device probe-order depenedencies. > It causes the same problem as the the kernel's ethX, just less likely. > Systemd cannot do that. > It doesn't invent them if they are part of the DCM string in the PCI VPD. >>> I don't think this makes much sense. If biosdevname had been >>> acceptable, the udev naming scheme would not have been introduced in >>> the first place. > > Right, the udev naming would not have been there or used the same > names if biosdevname was reliable, which it unfortunately isn't for > the above mentioned reasons, > >> biosdevname is going away in new version of RHEL, so we will lose the >> capability to detect if two 'virtual' NICs are actually the same >> physical NIC. The naming in systemd doesn't have the capabilty of >> showing relationship between physical/virtual (SR-IOV) NIC location >> name. >> At least on Dell systems, systemd generates unusable names (PCI B:D:F vs Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, but they do have a SMBIOS slot number. >>> >>> Wouldn't the better approach be to simply add SMBIOS support to udev >>> then? I must admit I don't know what challenges that entails, but >>> seems like a natural first step. >> >> That could be possible. I've tried submitti
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
20.10.2015 17:30, Jordan Hargrave пишет: On Tue, Oct 20, 2015 at 1:15 AM, Andrei Borzenkov wrote: On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave wrote: On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: Hi Jordan, On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave wrote: There are currently two competing naming mechanisms for network cards, biosdevname and systemd. Systemd currently has some limitations on naming cards that use network partitioning or support SR-IOV. Could you point to an example so we can fix it? I thought all bug reports had been handled, but maybe I lost track of something. I have a quad-port NIC: :40:00.0 = PCIE bridge (SMBIOS Slot 2) :41:00.0 = Ethernet Device (port1) :41:00.1 = Ethernet Device (port2) :42:00.0 = Ethernet Device (port3) :42:00.1 = Ethernet Device (port4) biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. How does it determine that 41 and 42 are the same device? I.e. how does it differ from real bridge with two independent two-port cards behind? Could you explain what information it is using? Is it exported in sysfs? ... It knows they are on the same slot as the parent device has SMBIOS Slot#2 (Type 9). So all child devices of a physical slot are on the same card. I'm currently using a patch to systemd that reads SMBIOS type 9. There isn't a kernel sysfs variable that displays this. This gives us slot ID, but how do we know which of function 0 on this slot ID is port 0 and which is port 2? There is nothing in SMBIOS description of Type 9 that answers it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Tue, Oct 20, 2015 at 3:02 PM, Andrei Borzenkov wrote: > 20.10.2015 17:30, Jordan Hargrave пишет: > >> On Tue, Oct 20, 2015 at 1:15 AM, Andrei Borzenkov >> wrote: >>> >>> On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave >>> wrote: On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: > > Hi Jordan, > > On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave > wrote: >> >> There are currently two competing naming mechanisms for network cards, >> biosdevname and systemd. Systemd currently has some limitations on >> naming >> cards that use network partitioning or support SR-IOV. > > > Could you point to an example so we can fix it? I thought all bug > reports had been handled, but maybe I lost track of something. > I have a quad-port NIC: :40:00.0 = PCIE bridge (SMBIOS Slot 2) :41:00.0 = Ethernet Device (port1) :41:00.1 = Ethernet Device (port2) :42:00.0 = Ethernet Device (port3) :42:00.1 = Ethernet Device (port4) biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. >>> >>> How does it determine that 41 and 42 are the same device? I.e. how >>> does it differ from real bridge with two independent two-port cards >>> behind? Could you explain what information it is using? Is it exported >>> in sysfs? >>> >>> ... >> >> >> It knows they are on the same slot as the parent device has SMBIOS >> Slot#2 (Type 9). So all child devices of a physical slot are on the >> same card. I'm currently using a patch to systemd that reads SMBIOS >> type 9. There isn't a kernel sysfs variable that displays this. >> > > This gives us slot ID, but how do we know which of function 0 on this slot > ID is port 0 and which is port 2? There is nothing in SMBIOS description of > Type 9 that answers it. Dell cards have an encoding in PCI VPD (DCM) that maps a PCI DevFn to port and instance. Here's an example system with loaded Qlogic, Broadcom, Intel cards. Intel supports SR-IOV DCM1001009d7F1402009d7F2101009d7F2502009d7F32010089154301008915 :01:00.0 port=1 instance=1 :01:00.4 port=1 instance=2 :01:00.1 port=2 instance=1 :01:00.5 port=2 instance=2 :01:00.2 port=3 instance=1 :01:00.3 port=4 instance=1 DCM100100015F120200015F140300015F160400015F210100015F230200015F250300015F270400015F :41:00.0 port=1 instance=1 :41:00.2 port=1 instance=2 :41:00.4 port=1 instance=3 :41:00.6 port=1 instance=4 :41:00.1 port=2 instance=1 :41:00.3 port=2 instance=2 :41:00.5 port=2 instance=3 :41:00.7 port=2 instance=4 DCM10010081D521010081D5 :43:00.0 port=1 instance=1 :43:00.1 port=2 instance=1 LSPCI has the following ethernet devices. :01:00.0 = Broadcom, port 1, instance 1 :01:00.1 port 2, instance 1 :01:00.2 port 3 :01:00.3 port 4 :01:00.4 port 1, instance 2 :01:00.5 port 2, instance 2 :41:00.0 = QLogic (PCIE slot 5), port 1, instance 1 :41:00.1 = port 2, instance 1 :41:00.2 = port 1, instance 2 :41:00.3 = port 2, instance 2 :41:00.4 = port 1, instance 3 :41:00.5 = port 2, instance 3 :41:00.6 = port 1, instance 4 :41:00.7 = port 2, instance 4 :43:00.0 = Intel (PCIE slot 2), port 1 :43:00.1 port 2 :43:10.0 vf port 1, instance 0 :43:10.1 vf port 2, instance 0 :43:10.2 vf port 1, instance 1 :43:10.3 vf port 2, instance 1 :43:10.4 vf port 1, instance 2 :43:10.5 vf port 2, instance 2 :43:10.6 vf port 1, instance 3 :43:10.7 vf port 2, instance 3 :43:11.0 vf port 1, instance 4 :43:11.1 etc.. :43:11.2 :43:11.3 :43:11.4 :43:11.5 :43:11.6 :43:11.7 :43:12.0 :43:12.1 :43:12.2 :43:12.3 :43:12.4 :43:12.5 :43:12.6 :43:12.7 :43:13.0 :43:13.1 :43:13.2 :43:13.3 :43:13.4 :43:13.5 :43:13.6 :43:13.7 :43:14.0 :43:14.1 :43:14.2 :43:14.3 :43:14.4 :43:14.5 :43:14.6 :43:14.7 :43:15.0 :43:15.1 :43:15.2 :43:15.3 :43:15.4 :43:15.5 :43:15.6 :43:15.7 :43:16.0 :43:16.1 :43:16.2 :43:16.3 :43:16.4 :43:16.5 :43:16.6 :43:16.7 :43:17.0 :43:17.1 :43:17.2 :43:17.3 :43:17.4 :43:17.5 :43:17.6 :43:17.7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Tue, Oct 20, 2015 at 10:04 PM, Jordan Hargrave wrote: > On Tue, Oct 20, 2015 at 3:02 PM, Andrei Borzenkov > wrote: > > 20.10.2015 17:30, Jordan Hargrave пишет: > > > >> On Tue, Oct 20, 2015 at 1:15 AM, Andrei Borzenkov > >> wrote: > >>> > >>> On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave > >>> wrote: > > On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen wrote: > > > > Hi Jordan, > > > > On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave > > wrote: > >> > >> There are currently two competing naming mechanisms for network > cards, > >> biosdevname and systemd. Systemd currently has some limitations on > >> naming > >> cards that use network partitioning or support SR-IOV. > > > > > > Could you point to an example so we can fix it? I thought all bug > > reports had been handled, but maybe I lost track of something. > > > > I have a quad-port NIC: > :40:00.0 = PCIE bridge (SMBIOS Slot 2) > :41:00.0 = Ethernet Device (port1) > :41:00.1 = Ethernet Device (port2) > :42:00.0 = Ethernet Device (port3) > :42:00.1 = Ethernet Device (port4) > > biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. > > >>> > >>> How does it determine that 41 and 42 are the same device? I.e. how > >>> does it differ from real bridge with two independent two-port cards > >>> behind? Could you explain what information it is using? Is it exported > >>> in sysfs? > >>> > >>> ... > >> > >> > >> It knows they are on the same slot as the parent device has SMBIOS > >> Slot#2 (Type 9). So all child devices of a physical slot are on the > >> same card. I'm currently using a patch to systemd that reads SMBIOS > >> type 9. There isn't a kernel sysfs variable that displays this. > >> > > > > This gives us slot ID, but how do we know which of function 0 on this > slot > > ID is port 0 and which is port 2? There is nothing in SMBIOS description > of > > Type 9 that answers it. > > Looking for a resolution for this.. adding port numbers to systemd enumeration of devices in PCI slots. Systemd still doesn't have the concept of a 'Port' number, so multi-port NICs get named with enpsf instead of ensp. There needs to be a way to generate systemd names that have the following variables for add-in cards: Slot Number Port Number Instance Number (for SR-IOV or Network Partitioned devices) It is possible to calculate the port number without any knowledge of sibling devices. Requires knowledge of device PCI ID, parent tree and 'dev_port' attribute (for mellanox cards). Then the devices could be named ensSLOTpPORT Network cards I've noticed have the following PCI bus topology: dual port cards: bus:00.0 = port 1 bus:00.1 = port 2 quad port cards have two different layouts: top level bus (upstream port) with two downstream ports, or all devices as multifunction Broadcom cards seem to follow this style bus:00.0 = port 1 bus:00.1 = port 2 bus:00.2 = port 3 bus:00.3 = port 4 Intel cards seem to follow this style bus:00.0 = upstream port. sbus is secondary bus sbus:xx.y = bridge 1 sbus:xx.z = bridge 2 sbus+1:00.0 = port 1 sbus+1:00.1 = port 2 sbus+2:00.0 = port 3 sbus+2:00.1 = port 4 Walking up the /sys/bus/pci/devices heirarchy from the network 'device' link until the 'acpi_index' field is found/ Then read sysfs 'label' field. On Dell systems this is the form "SLOT x" so the slot ID can be determined. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
Jordan Hargrave píše v Čt 04. 02. 2016 v 13:24 -0600: > > > On Tue, Oct 20, 2015 at 10:04 PM, Jordan Hargrave > wrote: > > On Tue, Oct 20, 2015 at 3:02 PM, Andrei Borzenkov < > > arvidj...@gmail.com> wrote: > > > 20.10.2015 17:30, Jordan Hargrave пишет: > > > > > >> On Tue, Oct 20, 2015 at 1:15 AM, Andrei Borzenkov < > > arvidj...@gmail.com> > > >> wrote: > > >>> > > >>> On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave < > > jhar...@gmail.com> > > >>> wrote: > > > > On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen > > wrote: > > > > > > Hi Jordan, > > > > > > On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave < > > jhar...@gmail.com> > > > wrote: > > >> > > >> There are currently two competing naming mechanisms for > > network cards, > > >> biosdevname and systemd. Systemd currently has some > > limitations on > > >> naming > > >> cards that use network partitioning or support SR-IOV. > > > > > > > > > Could you point to an example so we can fix it? I thought all > > bug > > > reports had been handled, but maybe I lost track of > > something. > > > > > > > I have a quad-port NIC: > > :40:00.0 = PCIE bridge (SMBIOS Slot 2) > > :41:00.0 = Ethernet Device (port1) > > :41:00.1 = Ethernet Device (port2) > > :42:00.0 = Ethernet Device (port3) > > :42:00.1 = Ethernet Device (port4) > > > > biosdevname would name these p2p1, p2p2, p2p3, p2p4 > > respectively. > > > > >>> > > >>> How does it determine that 41 and 42 are the same device? I.e. > > how > > >>> does it differ from real bridge with two independent two-port > > cards > > >>> behind? Could you explain what information it is using? Is it > > exported > > >>> in sysfs? > > >>> > > >>> ... > > >> > > >> > > >> It knows they are on the same slot as the parent device has > > SMBIOS > > >> Slot#2 (Type 9). So all child devices of a physical slot are on > > the > > >> same card. I'm currently using a patch to systemd that reads > > SMBIOS > > >> type 9. There isn't a kernel sysfs variable that displays this. > > >> > > > > > > This gives us slot ID, but how do we know which of function 0 on > > this slot > > > ID is port 0 and which is port 2? There is nothing in SMBIOS > > description of > > > Type 9 that answers it. > > > > > Looking for a resolution for this.. adding port numbers to systemd > enumeration of devices in PCI slots. > > Systemd still doesn't have the concept of a 'Port' number, so multi > -port NICs get named with enpsf instead of > ensp. > > There needs to be a way to generate systemd names that have the > following variables for add-in cards: > Slot Number > Port Number > Instance Number (for SR-IOV or Network Partitioned devices) > > It is possible to calculate the port number without any knowledge of > sibling devices. Requires knowledge of device PCI ID, parent tree > and 'dev_port' attribute (for mellanox cards). Then the devices could > be named ensSLOTpPORT Aren't we already doing that with: s[f][d] -- hotplug slot index number ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
