From: Tony Nguyen <anthony.l.nguyen@intel.com>
To: davem@davemloft.net, kuba@kernel.org
Cc: Brett Creeley <brett.creeley@intel.com>,
netdev@vger.kernel.org, sassmann@redhat.com,
anthony.l.nguyen@intel.com
Subject: [PATCH net-next 01/15] virtchnl: Use pad byte in virtchnl_ether_addr to specify MAC type
Date: Mon, 7 Jun 2021 09:53:11 -0700 [thread overview]
Message-ID: <20210607165325.182087-2-anthony.l.nguyen@intel.com> (raw)
In-Reply-To: <20210607165325.182087-1-anthony.l.nguyen@intel.com>
From: Brett Creeley <brett.creeley@intel.com>
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 | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/include/linux/avf/virtchnl.h b/include/linux/avf/virtchnl.h
index 565deea6ffe8..1fc07f3f99ab 100644
--- a/include/linux/avf/virtchnl.h
+++ b/include/linux/avf/virtchnl.h
@@ -412,9 +412,36 @@ VIRTCHNL_CHECK_STRUCT_LEN(12, virtchnl_queue_select);
* PF removes the filters and returns status.
*/
+/* VIRTCHNL_ETHER_ADDR_LEGACY
+ * Prior to adding the @type member to virtchnl_ether_addr, there were 2 pad
+ * bytes. Moving forward all VF drivers should not set type to
+ * VIRTCHNL_ETHER_ADDR_LEGACY. This is only here to not break previous/legacy
+ * behavior. The control plane function (i.e. PF) can use a best effort method
+ * of tracking the primary/device unicast in this case, but there is no
+ * guarantee and functionality depends on the implementation of the PF.
+ */
+
+/* VIRTCHNL_ETHER_ADDR_PRIMARY
+ * All VF drivers should set @type to VIRTCHNL_ETHER_ADDR_PRIMARY for the
+ * primary/device unicast MAC address filter for VIRTCHNL_OP_ADD_ETH_ADDR and
+ * VIRTCHNL_OP_DEL_ETH_ADDR. This allows for the underlying control plane
+ * function (i.e. PF) to accurately track and use this MAC address for
+ * displaying on the host and for VM/function reset.
+ */
+
+/* VIRTCHNL_ETHER_ADDR_EXTRA
+ * All VF drivers should set @type to VIRTCHNL_ETHER_ADDR_EXTRA for any extra
+ * unicast and/or multicast filters that are being added/deleted via
+ * VIRTCHNL_OP_DEL_ETH_ADDR/VIRTCHNL_OP_ADD_ETH_ADDR respectively.
+ */
struct virtchnl_ether_addr {
u8 addr[ETH_ALEN];
- u8 pad[2];
+ u8 type;
+#define VIRTCHNL_ETHER_ADDR_LEGACY 0
+#define VIRTCHNL_ETHER_ADDR_PRIMARY 1
+#define VIRTCHNL_ETHER_ADDR_EXTRA 2
+#define VIRTCHNL_ETHER_ADDR_TYPE_MASK 3 /* first two bits of type are valid */
+ u8 pad;
};
VIRTCHNL_CHECK_STRUCT_LEN(8, virtchnl_ether_addr);
--
2.26.2
next prev parent reply other threads:[~2021-06-07 16:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 16:53 [PATCH net-next 00/15][pull request] 100GbE Intel Wired LAN Driver Updates 2021-06-07 Tony Nguyen
2021-06-07 16:53 ` Tony Nguyen [this message]
2021-06-07 16:53 ` [PATCH net-next 02/15] ice: Manage VF's MAC address for both legacy and new cases Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 03/15] ice: Save VF's MAC across reboot Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 04/15] ice: Refactor ice_setup_rx_ctx Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 05/15] ice: Refactor VIRTCHNL_OP_CONFIG_VSI_QUEUES handling Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 06/15] ice: set the value of global config lock timeout longer Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 07/15] ice: Re-organizes reqstd/avail {R, T}XQ check/code for efficiency Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 08/15] ice: use static inline for dummy functions Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 09/15] ice: add extack when unable to read device caps Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 10/15] ice: add error message when pldmfw_flash_image fails Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 11/15] ice: wait for reset before reporting devlink info Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 12/15] ice: (re)initialize NVM fields when rebuilding Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 13/15] ice: Detect and report unsupported module power levels Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 14/15] ice: downgrade error print to debug print Tony Nguyen
2021-06-07 16:53 ` [PATCH net-next 15/15] ice: fix clang warning regarding deadcode.DeadStores Tony Nguyen
2021-06-07 20:40 ` [PATCH net-next 00/15][pull request] 100GbE Intel Wired LAN Driver Updates 2021-06-07 patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210607165325.182087-2-anthony.l.nguyen@intel.com \
--to=anthony.l.nguyen@intel.com \
--cc=brett.creeley@intel.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sassmann@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).