← Back to team overview

documentation-packages team mailing list archive

[Bug 1689616] Re: [SR-IOV]: Use static MAC addresses with udev rules for renaming VF interfaces (Mellanox CX4) (Documentation)



Could you please help answer Steve's questions ?

** Changed in: ubuntu-power-systems
     Assignee: (unassigned) => Breno Leitão (breno-leitao)

You received this bug notification because you are a member of
Documentation Packages, which is subscribed to ubuntu-docs in Ubuntu.

  [SR-IOV]: Use static MAC addresses with udev rules for renaming VF
  interfaces (Mellanox CX4) (Documentation)

Status in The Ubuntu-power-systems project:
Status in Release Notes for Ubuntu:
Status in ubuntu-docs package in Ubuntu:

Bug description:
  Problem Description
  The udev rules for renaming the SR-IOV Mellanox CX4 VF interface are not getting
  implemented. After setting the udev rules, and unbind/bind the drivers for the VF's, 
  the interface name still doesn't change. Same issue isn't noticed for the PF of the
  SR-IOV adapter.
  Use static MAC addresses for renaming SRIOV Mellanox CX4 VF interfaces with udev rules.

  With Mellanox CX4 SR-IOV when the VFs are created, each of them will get a random MAC address. 
  To be able to use the '70-persistent-net.rules' to define interfaces based on MAC Address, one need
  to set static MAC address to the VF. 

  This is an example
  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="02:a9:bb:cc:dd:00", NAME="enP4p1s0vf"

  First execute below command 
  echo 02:a9:bb:cc:dd:00 > /sys/class/infiniband/mlx5_0/device/sriov/0/mac

  and then 
  do the unbind/bind
  echo 0004:01:00.2 > /sys/bus/pci/drivers/mlx5_core/unbind
  echo 0004:01:00.2 > /sys/bus/pci/drivers/mlx5_core/bind

  then one can see  
  enP4p1s0vf: flags=4098<BROADCAST,MULTICAST>  mtu 1500
          ether 02:a9:bb:cc:dd:00  txqueuelen 1000  (Ethernet)
          RX packets 0  bytes 0 (0.0 B)
          RX errors 0  dropped 0  overruns 0  frame 0
          TX packets 0  bytes 0 (0.0 B)
          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

To manage notifications about this bug go to: