[PATCH 2/5] net/hns3: return ENOSPC if not enough MCAST filter resource
From: Dengdui Huang
Return ENOSPC instead of EINVAL when the hardware
has not enough multicast filtering resources.
Fixes: 7d7f9f80bbfb ("net/hns3: support MAC address related operations")
Cc: sta...@dpdk.org
Signed-off-by: Dengdui Huang
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hns3/hns3_common.c b/drivers/net/hns3/hns3_common.c
index a11ea686fd..043c7673b4 100644
--- a/drivers/net/hns3/hns3_common.c
+++ b/drivers/net/hns3/hns3_common.c
@@ -386,7 +386,7 @@ hns3_set_mc_addr_chk_param(struct hns3_hw *hw,
hns3_err(hw, "failed to set mc mac addr, nb_mc_addr(%u) "
"invalid. valid range: 0~%d",
nb_mc_addr, HNS3_MC_MACADDR_NUM);
- return -EINVAL;
+ return -ENOSPC;
}
/* Check if input mac addresses are valid */
--
2.22.0
[PATCH 0/5] net/hns3: some bugfixes for hns3
This patchset is to fix some bugs for hns3. Chengwen Feng (2): net/hns3: fix TM thread safety risk net/hns3: fix un-align format TM info Dengdui Huang (3): net/hns3: fix VF default MAC modified when set failed net/hns3: return ENOSPC if not enough MCAST filter resource net/hns3: flush multicast MAC address if mc_addr_set is NULL drivers/net/hns3/hns3_common.c| 12 ++- drivers/net/hns3/hns3_dump.c | 26 +++-- drivers/net/hns3/hns3_ethdev_vf.c | 2 + drivers/net/hns3/hns3_tm.c| 173 ++ 4 files changed, 179 insertions(+), 34 deletions(-) -- 2.22.0
[PATCH 3/5] net/hns3: flush multicast MAC address if mc_addr_set is NULL
From: Dengdui Huang
According rte_eth_dev_set_mc_addr_list() API definition,
support flush multicast MAC address if mc_addr_set is NULL
or nb_mc_addr is zero.
Fixes: 7d7f9f80bbfb ("net/hns3: support MAC address related operations")
Cc: sta...@dpdk.org
Signed-off-by: Dengdui Huang
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_common.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/hns3/hns3_common.c b/drivers/net/hns3/hns3_common.c
index 043c7673b4..c4d47f43fe 100644
--- a/drivers/net/hns3/hns3_common.c
+++ b/drivers/net/hns3/hns3_common.c
@@ -444,6 +444,7 @@ hns3_set_mc_mac_addr_list(struct rte_eth_dev *dev,
uint32_t nb_mc_addr)
{
struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
struct rte_ether_addr *addr;
int cur_addr_num;
int set_addr_num;
@@ -451,6 +452,15 @@ hns3_set_mc_mac_addr_list(struct rte_eth_dev *dev,
int ret;
int i;
+ if (mc_addr_set == NULL || nb_mc_addr == 0) {
+ rte_spinlock_lock(&hw->lock);
+ ret = hns3_configure_all_mc_mac_addr(hns, true);
+ if (ret == 0)
+ hw->mc_addrs_num = 0;
+ rte_spinlock_unlock(&hw->lock);
+ return ret;
+ }
+
/* Check if input parameters are valid */
ret = hns3_set_mc_addr_chk_param(hw, mc_addr_set, nb_mc_addr);
if (ret)
--
2.22.0
[PATCH 1/5] net/hns3: fix VF default MAC modified when set failed
From: Dengdui Huang
When the VF fail to set the default MAC address,
"hw->mac.mac_addr" should not be updated.
Fixes: a5475d61fa34 ("net/hns3: support VF")
Cc: sta...@dpdk.org
Signed-off-by: Dengdui Huang
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_ethdev_vf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c
b/drivers/net/hns3/hns3_ethdev_vf.c
index 5aac62a41f..ad0ccb82fe 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -250,6 +250,8 @@ hns3vf_set_default_mac_addr(struct rte_eth_dev *dev,
hns3_err(hw, "Failed to set mac addr(%s) for vf: %d",
mac_str, ret);
}
+ rte_spinlock_unlock(&hw->lock);
+ return ret;
}
rte_ether_addr_copy(mac_addr,
--
2.22.0
[PATCH 4/5] net/hns3: fix TM thread safety risk
From: Chengwen Feng
The driver-related TM (traffic management) info is implemented through
the linked list. The following threads are involved in the read and
write of the TM info:
1. main thread: invokes the rte_tm_xxx() API family to modify or read.
2. interrupt thread: will read TM info in reset recover process.
3. telemetry/proc-info thread: invoke rte_eth_dev_priv_dump() API to
read TM info.
Currently, thread safety protection of TM info is implemented only in
the following operations:
1. some of the rte_tm_xxx() API's implementation.
2. reset recover process.
Thread safety risks may exist in other scenarios, so fix by:
1. make sure all the rte_tm_xxx() API's implementations protected by
hw.lock.
2. make sure rte_eth_dev_priv_dump() API's implementation protected
by hw.lock.
Fixes: c09c7847d892 ("net/hns3: support traffic management")
Fixes: e4cfe6bb9114 ("net/hns3: dump TM configuration info")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_dump.c | 8 +-
drivers/net/hns3/hns3_tm.c | 173 ++-
2 files changed, 157 insertions(+), 24 deletions(-)
diff --git a/drivers/net/hns3/hns3_dump.c b/drivers/net/hns3/hns3_dump.c
index c0839380ea..67b45e6dc3 100644
--- a/drivers/net/hns3/hns3_dump.c
+++ b/drivers/net/hns3/hns3_dump.c
@@ -918,6 +918,8 @@ hns3_eth_dev_priv_dump(struct rte_eth_dev *dev, FILE *file)
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = &hns->hw;
+ rte_spinlock_lock(&hw->lock);
+
hns3_get_device_basic_info(file, dev);
hns3_get_dev_feature_capability(file, hw);
hns3_get_rxtx_queue_info(file, dev);
@@ -927,8 +929,10 @@ hns3_eth_dev_priv_dump(struct rte_eth_dev *dev, FILE *file)
* VF only supports dumping basic info, feature capability and queue
* info.
*/
- if (hns->is_vf)
+ if (hns->is_vf) {
+ rte_spinlock_unlock(&hw->lock);
return 0;
+ }
hns3_get_dev_mac_info(file, hns);
hns3_get_vlan_config_info(file, hw);
@@ -936,6 +940,8 @@ hns3_eth_dev_priv_dump(struct rte_eth_dev *dev, FILE *file)
hns3_get_tm_conf_info(file, dev);
hns3_get_flow_ctrl_info(file, dev);
+ rte_spinlock_unlock(&hw->lock);
+
return 0;
}
diff --git a/drivers/net/hns3/hns3_tm.c b/drivers/net/hns3/hns3_tm.c
index e1089b6bd0..67402a700f 100644
--- a/drivers/net/hns3/hns3_tm.c
+++ b/drivers/net/hns3/hns3_tm.c
@@ -1081,21 +1081,6 @@ hns3_tm_hierarchy_commit(struct rte_eth_dev *dev,
return -EINVAL;
}
-static int
-hns3_tm_hierarchy_commit_wrap(struct rte_eth_dev *dev,
- int clear_on_fail,
- struct rte_tm_error *error)
-{
- struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- int ret;
-
- rte_spinlock_lock(&hw->lock);
- ret = hns3_tm_hierarchy_commit(dev, clear_on_fail, error);
- rte_spinlock_unlock(&hw->lock);
-
- return ret;
-}
-
static int
hns3_tm_node_shaper_do_update(struct hns3_hw *hw,
uint32_t node_id,
@@ -1195,6 +1180,148 @@ hns3_tm_node_shaper_update(struct rte_eth_dev *dev,
return 0;
}
+static int
+hns3_tm_capabilities_get_wrap(struct rte_eth_dev *dev,
+ struct rte_tm_capabilities *cap,
+ struct rte_tm_error *error)
+{
+ struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ int ret;
+
+ rte_spinlock_lock(&hw->lock);
+ ret = hns3_tm_capabilities_get(dev, cap, error);
+ rte_spinlock_unlock(&hw->lock);
+
+ return ret;
+}
+
+static int
+hns3_tm_shaper_profile_add_wrap(struct rte_eth_dev *dev,
+ uint32_t shaper_profile_id,
+ struct rte_tm_shaper_params *profile,
+ struct rte_tm_error *error)
+{
+ struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ int ret;
+
+ rte_spinlock_lock(&hw->lock);
+ ret = hns3_tm_shaper_profile_add(dev, shaper_profile_id, profile,
error);
+ rte_spinlock_unlock(&hw->lock);
+
+ return ret;
+}
+
+static int
+hns3_tm_shaper_profile_del_wrap(struct rte_eth_dev *dev,
+ uint32_t shaper_profile_id,
+ struct rte_tm_error *error)
+{
+ struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ int ret;
+
+ rte_spinlock_lock(&hw->lock);
+ ret = hns3_tm_shaper_profile_del(dev, shaper_profile_id, error);
+ rte_spinlock_unlock(&hw->lock);
+
+ return ret;
+}
+
+static int
+hns3_tm_node_add_wrap(struct rte_eth_dev *dev, uint32_t node_id,
+ uint32_t parent_node_id, uint32_t priority,
+ uint32_t weight, uint32_t level_id,
+ struct rte_tm_node_p
[PATCH 5/5] net/hns3: fix un-align format TM info
From: Chengwen Feng
Currently the dumped TM info is un-align, which are:
- TM config info:
-- nb_leaf_nodes_max=64 nb_nodes_max=73
-- nb_shaper_profile=2 nb_tc_node=1 nb_queue_node=1
-- committed=0
shaper_profile:
id=800 reference_count=1 peak_rate=400Bps
id=801 reference_count=1 peak_rate=1200Bps
port_node:
...
This patch fix it, the new formatting:
- TM config info:
-- nb_leaf_nodes_max=256 nb_nodes_max=265
-- nb_shaper_profile=2 nb_tc_node=1 nb_queue_node=1
-- committed=1
-- shaper_profile:
id=800 reference_count=0 peak_rate=400Bps
id=801 reference_count=0 peak_rate=1200Bps
-- port_node:
...
Fixes: e4cfe6bb9114 ("net/hns3: dump TM configuration info")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_dump.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/hns3/hns3_dump.c b/drivers/net/hns3/hns3_dump.c
index 67b45e6dc3..5c21ff0a33 100644
--- a/drivers/net/hns3/hns3_dump.c
+++ b/drivers/net/hns3/hns3_dump.c
@@ -664,10 +664,10 @@ hns3_get_tm_conf_shaper_info(FILE *file, struct
hns3_tm_conf *conf)
if (conf->nb_shaper_profile == 0)
return;
- fprintf(file, " shaper_profile:\n");
+ fprintf(file, "\t -- shaper_profile:\n");
TAILQ_FOREACH(shaper_profile, shaper_profile_list, node) {
fprintf(file,
- "id=%u reference_count=%u peak_rate=%" PRIu64
"Bps\n",
+ "\t id=%u reference_count=%u peak_rate=%" PRIu64
"Bps\n",
shaper_profile->shaper_profile_id,
shaper_profile->reference_count,
shaper_profile->profile.peak.rate);
@@ -681,8 +681,8 @@ hns3_get_tm_conf_port_node_info(FILE *file, struct
hns3_tm_conf *conf)
return;
fprintf(file,
- " port_node:\n"
- "node_id=%u reference_count=%u shaper_profile_id=%d\n",
+ "\t -- port_node:\n"
+ "\t node_id=%u reference_count=%u shaper_profile_id=%d\n",
conf->root->id, conf->root->reference_count,
conf->root->shaper_profile ?
(int)conf->root->shaper_profile->shaper_profile_id : -1);
@@ -699,7 +699,7 @@ hns3_get_tm_conf_tc_node_info(FILE *file, struct
hns3_tm_conf *conf)
if (conf->nb_tc_node == 0)
return;
- fprintf(file, " tc_node:\n");
+ fprintf(file, "\t -- tc_node:\n");
memset(tc_node, 0, sizeof(tc_node));
TAILQ_FOREACH(tm_node, tc_list, node) {
tidx = hns3_tm_calc_node_tc_no(conf, tm_node->id);
@@ -712,7 +712,7 @@ hns3_get_tm_conf_tc_node_info(FILE *file, struct
hns3_tm_conf *conf)
if (tm_node == NULL)
continue;
fprintf(file,
- "id=%u TC%u reference_count=%u parent_id=%d "
+ "\t id=%u TC%u reference_count=%u parent_id=%d "
"shaper_profile_id=%d\n",
tm_node->id, hns3_tm_calc_node_tc_no(conf, tm_node->id),
tm_node->reference_count,
@@ -738,7 +738,7 @@ hns3_get_tm_conf_queue_format_info(FILE *file, struct
hns3_tm_node **queue_node,
end_queue_id = (i + 1) * HNS3_PERLINE_QUEUES - 1;
if (end_queue_id > nb_tx_queues - 1)
end_queue_id = nb_tx_queues - 1;
- fprintf(file, "%04u - %04u | ", start_queue_id,
+ fprintf(file, "\t %04u - %04u | ", start_queue_id,
end_queue_id);
for (j = start_queue_id; j < nb_tx_queues; j++) {
if (j >= end_queue_id + 1)
@@ -767,8 +767,8 @@ hns3_get_tm_conf_queue_node_info(FILE *file, struct
hns3_tm_conf *conf,
return;
fprintf(file,
- " queue_node:\n"
- "tx queue id | mapped tc (8 mean node not exist)\n");
+ "\t -- queue_node:\n"
+ "\t tx queue id | mapped tc (8 mean node not exist)\n");
memset(queue_node, 0, sizeof(queue_node));
memset(queue_node_tc, 0, sizeof(queue_node_tc));
--
2.22.0
RE: [PATCH] dumpcap: fix mbuf pool ring type
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Friday, 4 August 2023 18.16
>
> The ring used to store mbufs needs to be multiple producer,
> multiple consumer because multiple queues might on multiple
> cores might be allocating and same time (consume) and in
> case of ring full, the mbufs will be returned (multiple producer).
>
> Bugzilla ID: 1271
> Fixes: cb2440fd77af ("dumpcap: fix mbuf pool ring type")
> Signed-off-by: Stephen Hemminger
> ---
Reviewed-by: Morten Brørup
Re: [PATCH 4/5] net/hns3: fix TM thread safety risk
On Sat, 5 Aug 2023 16:36:26 +0800
Dongdong Liu wrote:
> From: Chengwen Feng
>
> The driver-related TM (traffic management) info is implemented through
> the linked list. The following threads are involved in the read and
> write of the TM info:
>
> 1. main thread: invokes the rte_tm_xxx() API family to modify or read.
> 2. interrupt thread: will read TM info in reset recover process.
> 3. telemetry/proc-info thread: invoke rte_eth_dev_priv_dump() API to
>read TM info.
>
> Currently, thread safety protection of TM info is implemented only in
> the following operations:
> 1. some of the rte_tm_xxx() API's implementation.
> 2. reset recover process.
>
> Thread safety risks may exist in other scenarios, so fix by:
> 1. make sure all the rte_tm_xxx() API's implementations protected by
>hw.lock.
> 2. make sure rte_eth_dev_priv_dump() API's implementation protected
>by hw.lock.
>
> Fixes: c09c7847d892 ("net/hns3: support traffic management")
> Fixes: e4cfe6bb9114 ("net/hns3: dump TM configuration info")
> Cc: sta...@dpdk.org
I hope no locking is necessary in the data path.
Re: Drivers, architectures, processor families, etc.
> On Aug 3, 2023, at 2:17 AM, Bruce Richardson > wrote: > > On Wed, Aug 02, 2023 at 03:47:59PM -0700, Stephen Hemminger wrote: >> On Wed, 2 Aug 2023 15:49:54 -0600 >> Philip Prindeville wrote: >> >>> Hi, >>> >>> I'm trying to come up with some Kconfig logic for OpenWRT packaging to help >>> users select the right build options for their hardware. >>> >>> Most OpenWRT developers typically cross-compile, so we obviously can't rely >>> on detection on the build host as that's rarely the same as the target >>> machine. >>> >>> Looking in the DPDK repo, I don't see any description of the available >>> architectures, drivers, etc. and what I had seen previously was (if I >>> remember) only for x86_64 hardware, and even that I can't seem to locate >>> again. >>> >>> Would it make sense to put some of these definitions into the repo itself, >>> so that when new drivers are added, that stands out (at least in the commit >>> logs) and we can capture the permutations of what driver goes with which >>> SoC on what architecture, etc? >>> >>> Thanks, >>> >>> -Philip >>> >> >> DPDK now uses meson which by default builds everything available on the >> build architecture. >> There is intentionally no way to disable drivers, you can disable some >> libraries though. > > Actually, we do now support disabling drivers, and also only selectively > enabling specific ones. See disable_drivers and enable_drivers meson > options. > > To find our different architecture support, I suggest looking in the config > directory. The subfolders there often contain cross-files for meson for > building for various architectures. For example, config/arm, contains a > number of reference files for cross-compiling for different arm platforms. > > Regards, > /Bruce Noticed also that the ARM architecture has configs, but AMD64 seems to be wide open... just one generic config. Is that because some chips, like Xeon-D have on-die NICs, and others like Xeon-E don't? -Philip
