1. 07 Jun, 2021 1 commit
    • Brett Creeley's avatar
      virtchnl: Use pad byte in virtchnl_ether_addr to specify MAC type · eb550f53
      Brett Creeley authored
      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: default avatarBrett Creeley <brett.creeley@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      eb550f53
  2. 04 Jun, 2021 26 commits
  3. 03 Jun, 2021 13 commits