udev rules: Add InfiniBand support
ATTR{type} 1 means ARPHRD_ETHER, 32 means ARPHRD_INFINIBAND. InfiniBand is supported in BIOS name, so add udev rules support.
@smlpan can you please take a look at this?
@superm1 @smlpan I tested with an Intel Omni-Path HFI Adapter. This is the biosdevname -d output.: $biosdevname -d BIOS device: p2p1 Kernel name: ib0 Permanent MAC: 80:00:00:02:FE:80 Assigned MAC : 80:00:00:02:FE:80 ifIndex: 7 Driver: ib_ipoib Driver version: 1.0.0 Firmware version: 0.0.0 Bus Info: 0000:5b:00.0 PCI name : 0000:5b:00.0 PCI Slot : 2 SMBIOS Label: Slot 2 Index in slot: 1
BIOS device is correct, so infiniband is supported by biosdevname. But the udev rule only support Ethernet. biosdevname_d.txt dmidecode_t_9_u.txt ip_link.txt lspci_t.txt Uploading lspci_vvv.txt…
Thanks for the comments @LenovoOpenLab . @smlpan or @jharg will need to confirm, I was just trying to loop in the right people for reviewing it.
Do we need to rename InfiniBand device interfaces with Ethernet device interface names? i think it may confuse or break five tools by treating InfiniBand interface as Ethernet interface
@prabhakarpujeri What tools may be effected?
I found treating InfiniBand interface as Ethernet interface really causes problems with infiniband tools such as ibdev2netdev. So we need to rename infiniband card. Indeed, this problem has already existed on Converged Ethernet card. ibdev2netdev can't recognize 'p1p1' name style.
even redhat certification tools try to run Ethernet tests on infiniband and its fails. primary intention of biosdevname is for ethernet interface
What we see here is an Infiniband PCIe card and the naming looks fine (if that is what the expected output is). But all this was manual calls till now. Opening the gates of biosdevname through udev for Infiniband will break biosdevname itself. I already see that biosdevname in its current state is not capable of handling a mix of Onboard Ethernet and Onboard Infiniband.
My question boils down to two things:
- Should we allow biosdevname to name interfaces other than Ethernet interfaces? I was planning to send a patch to ignore non-ethernet interfaces for manual call yesterday, but we can have the discussion here. https://linux.dell.com/files/.../consistent_network_device_naming_in_linux.pdf talks about Ethernet devices only. Hence my question on the Infiniband support.
- If above point is a Yes, then we should analyze the impact first.