[dpdk-dev] [PATCH] lib: librte_ether: fix RTE_PMD_DEBUG_TRACE macro
RTE_PMD_DEBUG_TRACE was changed also to support pedantic flag, but not completely. the macro changed only under the RTE_LIBRTE_ETHDEV_DEBUG define, but when RTE_LIBRTE_ETHDEV_DEBUG is not defined the old format was left. fix the macro to support pedantic flag in any case. Signed-off-by: Yaacov Hazan --- lib/librte_ether/rte_ethdev.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h index 1ff29e2..bada8ad 100644 --- a/lib/librte_ether/rte_ethdev.h +++ b/lib/librte_ether/rte_ethdev.h @@ -938,7 +938,7 @@ TAILQ_HEAD(rte_eth_dev_cb_list, rte_eth_dev_callback); #define RTE_PMD_DEBUG_TRACE(...) \ rte_pmd_debug_trace(__func__, __VA_ARGS__) #else -#define RTE_PMD_DEBUG_TRACE(fmt, args...) +#define RTE_PMD_DEBUG_TRACE(...) #endif -- 1.9.1
[dpdk-dev] Flow Director - big endian handling
Hi JingJing, I looked at your patch for flow director - app/testpmd: update flow director commands - a56335925919d26c81dec8accf31c39d2f790c5a. It seems there is some mismatch in the handling of big endian between the filter and mask. In the cmd_flow_director_filter_parsed function, which add the filter values, you called to rte_cpu_to_be_16 for the vlan_tci and ports values. But in cmd_flow_director_mask_parsed function, which set the mask, you didn't called to rte_cpu_to_be_16 for those values (valn_tci & ports). Does Intel's NICs (or Intel's PMDs) expected form application side to handle the big endian in different way for the filter values and the mask values? If yes, it is very confusing from the application/user point of view. I think that it is more make sense to leave the decision and handling of the big endian to the PMD layer, or at least to keep consistency for the expected handling in the application layer. Thanks, Yaacov.
[dpdk-dev] ethdev: fix link status race condition
Hi, I looked in your patch ethdev: fix link status race condition (d5790b03), and have a question. According to your change when dev_start is called and the device supports lsc we doesn't ask the device status. But, if the device is already up, when you start dpdk application, the application can't know that the status of the port is up since dev_start won't ask for the device status and no interrupt is trigger since no changed has been made (the device is already up). Can you please explain the idea of this patch? Thanks, Yaacov.
[dpdk-dev] [PATCH] net:bonding: fix free_queues function when no queues exist
From: Raslsn Darawsheh
In case of creating bond device without add any slaves and
quit from testpmd, application crashed since rx/tx queues
are NULL.
add checking of this paramters before trying to free.
Signed-off-by: Raslsn Darawsheh
Signed-off-by: Yaacov Hazan
---
drivers/net/bonding/rte_eth_bond_pmd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 5cc6372..40b63d7 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1518,12 +1518,18 @@ bond_ethdev_free_queues(struct rte_eth_dev *dev)
uint8_t i;
for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ if (dev->data->rx_queues[i] == NULL)
+ continue;
+
rte_free(dev->data->rx_queues[i]);
dev->data->rx_queues[i] = NULL;
}
dev->data->nb_rx_queues = 0;
for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ if (dev->data->tx_queues[i] == NULL)
+ continue;
+
rte_free(dev->data->tx_queues[i]);
dev->data->tx_queues[i] = NULL;
}
--
1.9.1
[dpdk-dev] [PATCH v2] net:bonding: fix free_queues function when no queues exist
From: Raslsn Darawsheh
In case of creating bond device without add any slaves and
quit from testpmd, application crashed since rx/tx queues
are NULL.
add checking of this paramters before trying to free.
Signed-off-by: Raslsn Darawsheh
Signed-off-by: Yaacov Hazan
---
in previous patch there was mismatch in the solution.
this patch is the correct fix for the described bug
drivers/net/bonding/rte_eth_bond_pmd.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 5cc6372..383fdcf 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1517,17 +1517,21 @@ bond_ethdev_free_queues(struct rte_eth_dev *dev)
{
uint8_t i;
- for (i = 0; i < dev->data->nb_rx_queues; i++) {
- rte_free(dev->data->rx_queues[i]);
- dev->data->rx_queues[i] = NULL;
+ if (dev->data->rx_queues != NULL) {
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ rte_free(dev->data->rx_queues[i]);
+ dev->data->rx_queues[i] = NULL;
+ }
+ dev->data->nb_rx_queues = 0;
}
- dev->data->nb_rx_queues = 0;
- for (i = 0; i < dev->data->nb_tx_queues; i++) {
- rte_free(dev->data->tx_queues[i]);
- dev->data->tx_queues[i] = NULL;
+ if (dev->data->tx_queues != NULL) {
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ rte_free(dev->data->tx_queues[i]);
+ dev->data->tx_queues[i] = NULL;
+ }
+ dev->data->nb_tx_queues = 0;
}
- dev->data->nb_tx_queues = 0;
}
void
--
1.9.1
[dpdk-dev] Bonding Active/Backup mode
Hi, I starting to check the bonding mode, and have a few questions about the Active - Backup mode (1). According to DPDK documentation and that is also what I saw in bond_pmd code. When we configure bond to Active/Backup mode, the bond port gets his MAC from the primary MAC, and the backup slave stay with his original MAC. When the Active slave go down and the backup slave become (the newly) Active there isn't any change in the MAC address of the bond or the newly Active. So the primary (active) MAC address is different form the Bond MAC address? Also, why packets that sent to specific MAC address (the formerly primary salve) will arrived to the new backup (that become primary and active) port if he stay with his original MAC address (not in promiscuous mode). Another thing that also related is, when you configure promiscuous it is applied only on the Active slave and not on the Backup salve. So the bond get packets with all MAC address (promiscuous mode). But after the Active slave go down, the code does not reconfigured the promiscuous mode on the new Active slave? So after the Active fall we maybe gets packets on the Backup slave but we are not in promiscuous mode anymore. Maybe I missed something.. I'll be happy to get some explanation. Thanks, Yaacov.
[dpdk-dev] [PATCH] mlx5: fix RETA table size
Change RETA table size to use 256 entries for better performance.
Fixes: ebb30ec64a68 ("mlx5: increase RETA table size")
Signed-off-by: Yaacov Hazan
---
drivers/net/mlx5/mlx5_defs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h
index 195440c..09207d9 100644
--- a/drivers/net/mlx5/mlx5_defs.h
+++ b/drivers/net/mlx5/mlx5_defs.h
@@ -52,7 +52,7 @@
#define MLX5_PMD_TX_PER_COMP_REQ 64
/* RSS Indirection table size. */
-#define RSS_INDIRECTION_TABLE_SIZE 512
+#define RSS_INDIRECTION_TABLE_SIZE 256
/* Maximum number of Scatter/Gather Elements per Work Request. */
#ifndef MLX5_PMD_SGE_WR_N
--
1.9.1
[dpdk-dev] [PATCH v2] mlx5: fix RETA table size
When the number of RX queues is not a power of two,
the RETA table is configured to its maximum size for
better balancing.
Testing showed that limiting its size to 256 improves performance
noticeably with little to no impact on balancing results.
Fixes: ebb30ec64a68 ("mlx5: increase RETA table size")
Signed-off-by: Yaacov Hazan
---
drivers/net/mlx5/mlx5_defs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h
index 195440c..09207d9 100644
--- a/drivers/net/mlx5/mlx5_defs.h
+++ b/drivers/net/mlx5/mlx5_defs.h
@@ -52,7 +52,7 @@
#define MLX5_PMD_TX_PER_COMP_REQ 64
/* RSS Indirection table size. */
-#define RSS_INDIRECTION_TABLE_SIZE 512
+#define RSS_INDIRECTION_TABLE_SIZE 256
/* Maximum number of Scatter/Gather Elements per Work Request. */
#ifndef MLX5_PMD_SGE_WR_N
--
1.9.1
