virtchnl: Use pad byte in virtchnl_ether_addr to specify MAC type
authorBrett Creeley <brett.creeley@intel.com>
Thu, 17 Sep 2020 20:13:33 +0000 (13:13 -0700)
committerTony Nguyen <anthony.l.nguyen@intel.com>
Mon, 7 Jun 2021 15:30:58 +0000 (08:30 -0700)
commiteb550f53099bf5ff8dc5de93e275378510c891c9
tree8d01a44ad72da43cf98dcba940634333015b73c5
parent1a42624aecba438f1d114430a14b640cdfa51c87
virtchnl: Use pad byte in virtchnl_ether_addr to specify MAC type

Currently, there is no way for a VF driver to specify that it wants to
change its device/primary unicast MAC address. This makes it
difficult/impossible for the PF driver to track the VF's device/primary
unicast MAC address, which is used for VM/VF reboot and displaying on
the host. Fix this by using 2 bits of a pad byte in the
virtchnl_ether_addr structure so the VF can specify what type of MAC
it's adding/deleting.

Below are the values that should be used by all VF drivers going
forward.

VIRTCHNL_ETHER_ADDR_LEGACY(0):
- The type should only ever be 0 for legacy AVF drivers (i.e.
  drivers that don't support the new type bits). The PF drivers
  will track VF's device/primary unicast MAC, but this will only
  be a best effort.

VIRTCHNL_ETHER_ADDR_PRIMARY(1):
- This type should only be used when the VF is changing their
  device/primary unicast MAC. It should be used for both delete
  and add cases related to the device/primary unicast MAC.

VIRTCHNL_ETHER_ADDR_EXTRA(2):
- This type should be used when the VF is adding and/or deleting
  MAC addresses that are not the device/primary unicast MAC. For
  example, extra unicast addresses and multicast addresses
  assuming the PF supports "extra" addresses at all.

If a PF is parsing the type field of the virtchnl_ether_addr, then it
should use the VIRTCHNL_ETHER_ADDR_TYPE_MASK to mask the first two bits
of the type field since 0, 1, and 2 are the only valid values.

Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
include/linux/avf/virtchnl.h