From: Dariusz Sosnowski <dsosnowski@nvidia.com>
To: Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
Bing Zhao <bingz@nvidia.com>, Ori Kam <orika@nvidia.com>,
Suanming Mou <suanmingm@nvidia.com>,
Matan Azrad <matan@nvidia.com>
Cc: <dev@dpdk.org>
Subject: [PATCH v2 10/10] net/mlx5: optimize MAC address and VLAN filter handling
Date: Tue, 22 Oct 2024 14:06:18 +0200 [thread overview]
Message-ID: <20241022120618.512091-11-dsosnowski@nvidia.com> (raw)
In-Reply-To: <20241022120618.512091-1-dsosnowski@nvidia.com>
This patch:
- Changes MAC address adding/removing handling, so that
only required control rules are added/removed.
As a result, rte_eth_dev_mac_addr_add() or
rte_eth_dev_mac_addr_remove() calls are faster for mlx5 PMD.
- Changes VLAN filtering handling, so that
only required control flow rules are added/removed.
As a result, rte_eth_dev_vlan_filter() call is faster for mlx5 PMD.
Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
---
drivers/net/mlx5/mlx5_mac.c | 41 +++++++++++++++++++++++++-----------
drivers/net/mlx5/mlx5_vlan.c | 9 ++++----
2 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_mac.c b/drivers/net/mlx5/mlx5_mac.c
index 22a756a52b..0e5d2be530 100644
--- a/drivers/net/mlx5/mlx5_mac.c
+++ b/drivers/net/mlx5/mlx5_mac.c
@@ -25,15 +25,25 @@
* Pointer to Ethernet device structure.
* @param index
* MAC address index.
+ * @param addr
+ * If MAC address is actually removed, it will be stored here if pointer is not a NULL.
+ *
+ * @return
+ * True if there was a MAC address under given index.
*/
-static void
-mlx5_internal_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index)
+static bool
+mlx5_internal_mac_addr_remove(struct rte_eth_dev *dev,
+ uint32_t index,
+ struct rte_ether_addr *addr)
{
MLX5_ASSERT(index < MLX5_MAX_MAC_ADDRESSES);
if (rte_is_zero_ether_addr(&dev->data->mac_addrs[index]))
- return;
+ return false;
mlx5_os_mac_addr_remove(dev, index);
+ if (addr != NULL)
+ *addr = dev->data->mac_addrs[index];
memset(&dev->data->mac_addrs[index], 0, sizeof(struct rte_ether_addr));
+ return true;
}
/**
@@ -91,15 +101,15 @@ mlx5_internal_mac_addr_add(struct rte_eth_dev *dev, struct rte_ether_addr *mac,
void
mlx5_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index)
{
+ struct rte_ether_addr addr = { 0 };
int ret;
if (index >= MLX5_MAX_UC_MAC_ADDRESSES)
return;
- mlx5_internal_mac_addr_remove(dev, index);
- if (!dev->data->promiscuous) {
- ret = mlx5_traffic_restart(dev);
+ if (mlx5_internal_mac_addr_remove(dev, index, &addr)) {
+ ret = mlx5_traffic_mac_remove(dev, &addr);
if (ret)
- DRV_LOG(ERR, "port %u cannot restart traffic: %s",
+ DRV_LOG(ERR, "port %u cannot update control flow rules: %s",
dev->data->port_id, strerror(rte_errno));
}
}
@@ -132,9 +142,7 @@ mlx5_mac_addr_add(struct rte_eth_dev *dev, struct rte_ether_addr *mac,
ret = mlx5_internal_mac_addr_add(dev, mac, index);
if (ret < 0)
return ret;
- if (!dev->data->promiscuous)
- return mlx5_traffic_restart(dev);
- return 0;
+ return mlx5_traffic_mac_add(dev, mac);
}
/**
@@ -154,6 +162,12 @@ mlx5_mac_addr_set(struct rte_eth_dev *dev, struct rte_ether_addr *mac_addr)
uint16_t port_id;
struct mlx5_priv *priv = dev->data->dev_private;
struct mlx5_priv *pf_priv;
+ struct rte_ether_addr old_mac_addr = dev->data->mac_addrs[0];
+ int ret;
+
+ /* ethdev does not check if new default address is the same as the old one. */
+ if (rte_is_same_ether_addr(mac_addr, &old_mac_addr))
+ return 0;
/*
* Configuring the VF instead of its representor,
@@ -188,7 +202,10 @@ mlx5_mac_addr_set(struct rte_eth_dev *dev, struct rte_ether_addr *mac_addr)
DRV_LOG(DEBUG, "port %u setting primary MAC address",
dev->data->port_id);
- return mlx5_mac_addr_add(dev, mac_addr, 0, 0);
+ ret = mlx5_mac_addr_add(dev, mac_addr, 0, 0);
+ if (ret)
+ return ret;
+ return mlx5_traffic_mac_remove(dev, &old_mac_addr);
}
/**
@@ -208,7 +225,7 @@ mlx5_set_mc_addr_list(struct rte_eth_dev *dev,
return -rte_errno;
}
for (i = MLX5_MAX_UC_MAC_ADDRESSES; i != MLX5_MAX_MAC_ADDRESSES; ++i)
- mlx5_internal_mac_addr_remove(dev, i);
+ mlx5_internal_mac_addr_remove(dev, i, NULL);
i = MLX5_MAX_UC_MAC_ADDRESSES;
while (nb_mc_addr--) {
ret = mlx5_internal_mac_addr_add(dev, mc_addr_set++, i++);
diff --git a/drivers/net/mlx5/mlx5_vlan.c b/drivers/net/mlx5/mlx5_vlan.c
index e7161b66fe..43a314a679 100644
--- a/drivers/net/mlx5/mlx5_vlan.c
+++ b/drivers/net/mlx5/mlx5_vlan.c
@@ -54,7 +54,7 @@ mlx5_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
MLX5_ASSERT(priv->vlan_filter_n != 0);
/* Enabling an existing VLAN filter has no effect. */
if (on)
- goto out;
+ goto no_effect;
/* Remove VLAN filter from list. */
--priv->vlan_filter_n;
memmove(&priv->vlan_filter[i],
@@ -66,14 +66,13 @@ mlx5_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
MLX5_ASSERT(i == priv->vlan_filter_n);
/* Disabling an unknown VLAN filter has no effect. */
if (!on)
- goto out;
+ goto no_effect;
/* Add new VLAN filter. */
priv->vlan_filter[priv->vlan_filter_n] = vlan_id;
++priv->vlan_filter_n;
}
-out:
- if (dev->data->dev_started)
- return mlx5_traffic_restart(dev);
+ return on ? mlx5_traffic_vlan_add(dev, vlan_id) : mlx5_traffic_vlan_remove(dev, vlan_id);
+no_effect:
return 0;
}
--
2.39.5
next prev parent reply other threads:[~2024-10-22 12:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 7:57 [PATCH 00/10] net/mlx5: improve MAC address and VLAN add latency Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 01/10] net/mlx5: track unicast DMAC control flow rules Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 02/10] net/mlx5: add checking if unicast flow rule exists Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 03/10] net/mlx5: rework creation of unicast flow rules Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 04/10] net/mlx5: support destroying " Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 05/10] net/mlx5: rename control flow rules types Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 06/10] net/mlx5: shared init of control flow rules Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 07/10] net/mlx5: add legacy unicast flow rules management Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 08/10] net/mlx5: add legacy unicast flow rule registration Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 09/10] net/mlx5: add dynamic unicast flow rule management Dariusz Sosnowski
2024-10-17 7:57 ` [PATCH 10/10] net/mlx5: optimize MAC address and VLAN filter handling Dariusz Sosnowski
2024-10-17 8:01 ` [PATCH 00/10] net/mlx5: improve MAC address and VLAN add latency Slava Ovsiienko
2024-10-22 12:06 ` [PATCH v2 " Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 01/10] net/mlx5: track unicast DMAC control flow rules Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 02/10] net/mlx5: add checking if unicast flow rule exists Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 03/10] net/mlx5: rework creation of unicast flow rules Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 04/10] net/mlx5: support destroying " Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 05/10] net/mlx5: rename control flow rules types Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 06/10] net/mlx5: shared init of control flow rules Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 07/10] net/mlx5: add legacy unicast flow rules management Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 08/10] net/mlx5: add legacy unicast flow rule registration Dariusz Sosnowski
2024-10-22 12:06 ` [PATCH v2 09/10] net/mlx5: add dynamic unicast flow rule management Dariusz Sosnowski
2024-10-22 12:06 ` Dariusz Sosnowski [this message]
2024-10-22 15:41 ` [PATCH v2 00/10] net/mlx5: improve MAC address and VLAN add latency Stephen Hemminger
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=20241022120618.512091-11-dsosnowski@nvidia.com \
--to=dsosnowski@nvidia.com \
--cc=bingz@nvidia.com \
--cc=dev@dpdk.org \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=suanmingm@nvidia.com \
--cc=viacheslavo@nvidia.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).