[dpdk-dev] [PATCH] i40e: merge two duplicate functions together
The functions i40e_vsi_dump_bw_config and i40e_vsi_get_bw_info do
the similar actions on BW configuration of vsi. It is necessary
to merge them together to avoid functions duplication.
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 99 +-
1 file changed, 30 insertions(+), 69 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2c51a0b..57ee130 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3789,14 +3789,21 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
return i40e_vsi_add_mac(vsi, &filter);
}
+/*
+ * i40e_vsi_get_bw_config - Query VSI BW Information
+ * @vsi: the VSI to be queried
+ *
+ * Returns 0 on success, negative value on failure
+ */
static int
-i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
+i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
{
struct i40e_aqc_query_vsi_bw_config_resp bw_config;
struct i40e_aqc_query_vsi_ets_sla_config_resp ets_sla_config;
struct i40e_hw *hw = &vsi->adapter->hw;
i40e_status ret;
int i;
+ uint32_t tc_bw_max;
memset(&bw_config, 0, sizeof(bw_config));
ret = i40e_aq_query_vsi_bw_config(hw, vsi->seid, &bw_config, NULL);
@@ -3815,7 +3822,7 @@ i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
return ret;
}
- /* Not store the info yet, just print out */
+ /* print BW info */
PMD_DRV_LOG(INFO, "VSI bw limit:%u", bw_config.port_bw_limit);
PMD_DRV_LOG(INFO, "VSI max_bw:%u", bw_config.max_bw);
for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
@@ -3828,6 +3835,24 @@ i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
(i * 4));
}
+ /* store BW info */
+ vsi->bw_info.bw_limit = rte_le_to_cpu_16(bw_config.port_bw_limit);
+ vsi->bw_info.bw_max_quanta = bw_config.max_bw;
+ tc_bw_max = rte_le_to_cpu_16(ets_sla_config.tc_bw_max[0]) |
+ (rte_le_to_cpu_16(ets_sla_config.tc_bw_max[1]) << 16);
+ for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
+ vsi->bw_info.bw_ets_share_credits[i] =
+ ets_sla_config.share_credits[i];
+ vsi->bw_info.bw_ets_limit_credits[i] =
+ rte_le_to_cpu_16(ets_sla_config.credits[i]);
+ /* 3 bits out of 4 for each TC */
+ vsi->bw_info.bw_ets_max_quanta[i] =
+ (uint8_t)((tc_bw_max >> (i * 4)) & 0x7);
+ PMD_INIT_LOG(DEBUG,
+"%s: vsi seid = %d, TC = %d, qset = 0x%x\n",
+__func__, vsi->seid, i, bw_config.qs_handles[i]);
+ }
+
return 0;
}
@@ -4154,7 +4179,7 @@ i40e_vsi_setup(struct i40e_pf *pf,
}
/* Get VSI BW information */
- i40e_vsi_dump_bw_config(vsi);
+ i40e_vsi_get_bw_config(vsi);
return vsi;
fail_msix_alloc:
i40e_res_pool_free(&pf->msix_pool,vsi->msix_intr);
@@ -8081,70 +8106,6 @@ i40e_parse_dcb_configure(struct rte_eth_dev *dev,
return 0;
}
-/*
- * i40e_vsi_get_bw_info - Query VSI BW Information
- * @vsi: the VSI being queried
- *
- * Returns 0 on success, negative value on failure
- */
-static enum i40e_status_code
-i40e_vsi_get_bw_info(struct i40e_vsi *vsi)
-{
- struct i40e_aqc_query_vsi_ets_sla_config_resp bw_ets_config = {0};
- struct i40e_aqc_query_vsi_bw_config_resp bw_config = {0};
- struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
- enum i40e_status_code ret;
- int i;
- uint32_t tc_bw_max;
-
- /* Get the VSI level BW configuration */
- ret = i40e_aq_query_vsi_bw_config(hw, vsi->seid, &bw_config, NULL);
- if (ret) {
- PMD_INIT_LOG(ERR,
-"couldn't get PF vsi bw config, err %s aq_err %s\n",
-i40e_stat_str(hw, ret),
-i40e_aq_str(hw, hw->aq.asq_last_status));
- return ret;
- }
-
- /* Get the VSI level BW configuration per TC */
- ret = i40e_aq_query_vsi_ets_sla_config(hw, vsi->seid, &bw_ets_config,
- NULL);
- if (ret) {
- PMD_INIT_LOG(ERR,
-"couldn't get PF vsi ets bw config, err %s aq_err
%s\n",
-i40e_stat_str(hw, ret),
-i40e_aq_str(hw, hw->aq.asq_last_status));
- return ret;
- }
-
- if (bw_config.tc_valid_bits != bw_ets_config.tc_valid_bits) {
- PMD_INIT_LOG(WARNING,
-"Enabled TCs mismatch from querying VSI BW info"
-" 0x%08x 0x%08x\n", bw_config.tc_valid_bits,
-bw_ets_config.tc_valid_bits);
- /* Still continuing */
- }
-
- vsi->bw_info.bw_limit = rte_le_to_cpu_16(bw_config.port_bw_limit);
- vsi->bw_info.bw
[dpdk-dev] compiling pktgen w/ DPDK 2.1.0 and master seems broken
Hello, There are some really weird errors if you try to compile pktgen using DPDK 2.1.0. No matter what I try, the logic in the DPDK external app *.mk files seems to mess up the value of RTE_OUTPUT. I tried tracing through the *.mk and I found various places where it was set right and various places where it was set wrong but never narrowed it down to a more specific spot. It appears to involve Makefiles in subdirs, and rte.extsubdir.mk, but I can't figure out what is happening. Also, if I try compiling pktgen against master, then I get some new problems: app/pktgen-stats.c:308:9: error: ibadcrc is deprecated [-Werror=deprecated-declarations] app/pktgen-stats.c:309:9: error: ibadlen is deprecated [-Werror=deprecated-declarations] What is the secret recipe people are using to get this thing to compile right? Did I miss something? Matthew. mhall at mvs-01:~/src/sdn_sensor/external/pktgen-dpdk$ export RTE_TARGET=x86_64-native-linuxapp-gcc mhall at mvs-01:~/src/sdn_sensor/external/pktgen-dpdk$ export RTE_SDK=$(realpath ~/dpdk/) mhall at mvs-01:~/src/sdn_sensor/external/pktgen-dpdk$ make V=1 SHELL="/bin/sh -x" + [ -d /home/mhall/src/sdn_sensor/external/pktgen-dpdk/lib/common/lib/common/x86_64-native-linuxapp-gcc/lib ] + cp -f wr_copyright_info.o wr_port_config.o wr_core_info.o wr_lscpu.o wr_utils.o wr_coremap.o wr_pcap.o wr_cksum.o wr_l2p.o wr_scrn.o /home/mhall/src/sdn_sensor/external/pktgen-dpdk/lib/common/lib/common/x86_64-native-linuxapp-gcc/build/lib cp: target /home/mhall/src/sdn_sensor/external/pktgen-dpdk/lib/common/lib/common/x86_64-native-linuxapp-gcc/build/lib is not a directory /home/mhall/src/sdn_sensor/external/dpdk/mk/rte.lib.mk:146: recipe for target 'libcommon.a' failed make[3]: *** [libcommon.a] Error 1 /home/mhall/src/sdn_sensor/external/dpdk/mk/rte.extlib.mk:42: recipe for target 'all' failed make[2]: *** [all] Error 2 /home/mhall/src/sdn_sensor/external/dpdk/mk/rte.extsubdir.mk:46: recipe for target 'common' failed make[1]: *** [common] Error 2 /home/mhall/src/sdn_sensor/external/dpdk/mk/rte.extsubdir.mk:46: recipe for target 'lib' failed make: *** [lib] Error 2
[dpdk-dev] [PATCH] i40e: fix BW info update if no dcb enabled
If DCB is not enabled, the BW info is not stored for VSI. This
patch fixes this issue by merging functions i40e_vsi_dump_bw_config
and i40e_vsi_get_bw_info together.
Fixes: c8b9a3e3fe1b (i40e: support DCB mode)
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 112 +
drivers/net/i40e/i40e_ethdev.h | 12 ++---
2 files changed, 40 insertions(+), 84 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2c51a0b..d7d7a08 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3789,14 +3789,22 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
return i40e_vsi_add_mac(vsi, &filter);
}
+#define I40E_3_BIT_MASK 0x7
+/*
+ * i40e_vsi_get_bw_config - Query VSI BW Information
+ * @vsi: the VSI to be queried
+ *
+ * Returns 0 on success, negative value on failure
+ */
static int
-i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
+i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
{
struct i40e_aqc_query_vsi_bw_config_resp bw_config;
struct i40e_aqc_query_vsi_ets_sla_config_resp ets_sla_config;
struct i40e_hw *hw = &vsi->adapter->hw;
i40e_status ret;
int i;
+ uint32_t bw_max;
memset(&bw_config, 0, sizeof(bw_config));
ret = i40e_aq_query_vsi_bw_config(hw, vsi->seid, &bw_config, NULL);
@@ -3815,17 +3823,29 @@ i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
return ret;
}
- /* Not store the info yet, just print out */
- PMD_DRV_LOG(INFO, "VSI bw limit:%u", bw_config.port_bw_limit);
- PMD_DRV_LOG(INFO, "VSI max_bw:%u", bw_config.max_bw);
+ /* store and print out BW info */
+ vsi->bw_info.bw_limit = rte_le_to_cpu_16(bw_config.port_bw_limit);
+ vsi->bw_info.bw_max = bw_config.max_bw;
+ PMD_DRV_LOG(DEBUG, "VSI bw limit:%u", bw_config.port_bw_limit);
+ PMD_DRV_LOG(DEBUG, "VSI max_bw:%u", bw_config.max_bw);
+ bw_max = rte_le_to_cpu_16(ets_sla_config.tc_bw_max[0]) |
+ (rte_le_to_cpu_16(ets_sla_config.tc_bw_max[1]) <<
+I40E_16_BIT_WIDTH);
for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
- PMD_DRV_LOG(INFO, "\tVSI TC%u:share credits %u", i,
- ets_sla_config.share_credits[i]);
- PMD_DRV_LOG(INFO, "\tVSI TC%u:credits %u", i,
- rte_le_to_cpu_16(ets_sla_config.credits[i]));
- PMD_DRV_LOG(INFO, "\tVSI TC%u: max credits: %u", i,
- rte_le_to_cpu_16(ets_sla_config.credits[i / 4]) >>
- (i * 4));
+ vsi->bw_info.bw_ets_share_credits[i] =
+ ets_sla_config.share_credits[i];
+ vsi->bw_info.bw_ets_credits[i] =
+ rte_le_to_cpu_16(ets_sla_config.credits[i]);
+ /* 4 bits per TC, 4th bit is reserved */
+ vsi->bw_info.bw_ets_max[i] =
+ (uint8_t)((bw_max >> (i * I40E_4_BIT_WIDTH)) &
+ I40E_3_BIT_MASK);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u:share credits %u", i,
+ vsi->bw_info.bw_ets_share_credits[i]);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u:credits %u", i,
+ vsi->bw_info.bw_ets_credits[i]);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u: max credits: %u", i,
+ vsi->bw_info.bw_ets_max[i]);
}
return 0;
@@ -4154,7 +4174,7 @@ i40e_vsi_setup(struct i40e_pf *pf,
}
/* Get VSI BW information */
- i40e_vsi_dump_bw_config(vsi);
+ i40e_vsi_get_bw_config(vsi);
return vsi;
fail_msix_alloc:
i40e_res_pool_free(&pf->msix_pool,vsi->msix_intr);
@@ -8081,70 +8101,6 @@ i40e_parse_dcb_configure(struct rte_eth_dev *dev,
return 0;
}
-/*
- * i40e_vsi_get_bw_info - Query VSI BW Information
- * @vsi: the VSI being queried
- *
- * Returns 0 on success, negative value on failure
- */
-static enum i40e_status_code
-i40e_vsi_get_bw_info(struct i40e_vsi *vsi)
-{
- struct i40e_aqc_query_vsi_ets_sla_config_resp bw_ets_config = {0};
- struct i40e_aqc_query_vsi_bw_config_resp bw_config = {0};
- struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
- enum i40e_status_code ret;
- int i;
- uint32_t tc_bw_max;
-
- /* Get the VSI level BW configuration */
- ret = i40e_aq_query_vsi_bw_config(hw, vsi->seid, &bw_config, NULL);
- if (ret) {
- PMD_INIT_LOG(ERR,
-"couldn't get PF vsi bw config, err %s aq_err %s\n",
-i40e_stat_str(hw, ret),
-i40e_aq_str(hw, hw->aq.asq_last_status));
- return ret;
- }
-
- /* Get the VSI level BW configuration per TC */
- ret = i40e_aq_query_vsi_ets_sla_config(hw, vsi->seid, &bw_ets_config,
-
[dpdk-dev] [PATCH v2] i40e: fix BW info update if no dcb enabled
If DCB is not enabled, the BW info is not stored for VSI. This
patch fixes this issue by merging functions i40e_vsi_dump_bw_config
and i40e_vsi_get_bw_info together.
Fixes: c8b9a3e3fe1b (i40e: support DCB mode)
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 112 +
drivers/net/i40e/i40e_ethdev.h | 12 ++---
2 files changed, 40 insertions(+), 84 deletions(-)
v2 changes:
- correct the value used in debug log.
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2c51a0b..d6b9f62 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3789,14 +3789,22 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
return i40e_vsi_add_mac(vsi, &filter);
}
+#define I40E_3_BIT_MASK 0x7
+/*
+ * i40e_vsi_get_bw_config - Query VSI BW Information
+ * @vsi: the VSI to be queried
+ *
+ * Returns 0 on success, negative value on failure
+ */
static int
-i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
+i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
{
struct i40e_aqc_query_vsi_bw_config_resp bw_config;
struct i40e_aqc_query_vsi_ets_sla_config_resp ets_sla_config;
struct i40e_hw *hw = &vsi->adapter->hw;
i40e_status ret;
int i;
+ uint32_t bw_max;
memset(&bw_config, 0, sizeof(bw_config));
ret = i40e_aq_query_vsi_bw_config(hw, vsi->seid, &bw_config, NULL);
@@ -3815,17 +3823,29 @@ i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
return ret;
}
- /* Not store the info yet, just print out */
- PMD_DRV_LOG(INFO, "VSI bw limit:%u", bw_config.port_bw_limit);
- PMD_DRV_LOG(INFO, "VSI max_bw:%u", bw_config.max_bw);
+ /* store and print out BW info */
+ vsi->bw_info.bw_limit = rte_le_to_cpu_16(bw_config.port_bw_limit);
+ vsi->bw_info.bw_max = bw_config.max_bw;
+ PMD_DRV_LOG(DEBUG, "VSI bw limit:%u", vsi->bw_info.bw_limit);
+ PMD_DRV_LOG(DEBUG, "VSI max_bw:%u", vsi->bw_info.bw_max);
+ bw_max = rte_le_to_cpu_16(ets_sla_config.tc_bw_max[0]) |
+ (rte_le_to_cpu_16(ets_sla_config.tc_bw_max[1]) <<
+I40E_16_BIT_WIDTH);
for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
- PMD_DRV_LOG(INFO, "\tVSI TC%u:share credits %u", i,
- ets_sla_config.share_credits[i]);
- PMD_DRV_LOG(INFO, "\tVSI TC%u:credits %u", i,
- rte_le_to_cpu_16(ets_sla_config.credits[i]));
- PMD_DRV_LOG(INFO, "\tVSI TC%u: max credits: %u", i,
- rte_le_to_cpu_16(ets_sla_config.credits[i / 4]) >>
- (i * 4));
+ vsi->bw_info.bw_ets_share_credits[i] =
+ ets_sla_config.share_credits[i];
+ vsi->bw_info.bw_ets_credits[i] =
+ rte_le_to_cpu_16(ets_sla_config.credits[i]);
+ /* 4 bits per TC, 4th bit is reserved */
+ vsi->bw_info.bw_ets_max[i] =
+ (uint8_t)((bw_max >> (i * I40E_4_BIT_WIDTH)) &
+ I40E_3_BIT_MASK);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u:share credits %u", i,
+ vsi->bw_info.bw_ets_share_credits[i]);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u:credits %u", i,
+ vsi->bw_info.bw_ets_credits[i]);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u: max credits: %u", i,
+ vsi->bw_info.bw_ets_max[i]);
}
return 0;
@@ -4154,7 +4174,7 @@ i40e_vsi_setup(struct i40e_pf *pf,
}
/* Get VSI BW information */
- i40e_vsi_dump_bw_config(vsi);
+ i40e_vsi_get_bw_config(vsi);
return vsi;
fail_msix_alloc:
i40e_res_pool_free(&pf->msix_pool,vsi->msix_intr);
@@ -8081,70 +8101,6 @@ i40e_parse_dcb_configure(struct rte_eth_dev *dev,
return 0;
}
-/*
- * i40e_vsi_get_bw_info - Query VSI BW Information
- * @vsi: the VSI being queried
- *
- * Returns 0 on success, negative value on failure
- */
-static enum i40e_status_code
-i40e_vsi_get_bw_info(struct i40e_vsi *vsi)
-{
- struct i40e_aqc_query_vsi_ets_sla_config_resp bw_ets_config = {0};
- struct i40e_aqc_query_vsi_bw_config_resp bw_config = {0};
- struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
- enum i40e_status_code ret;
- int i;
- uint32_t tc_bw_max;
-
- /* Get the VSI level BW configuration */
- ret = i40e_aq_query_vsi_bw_config(hw, vsi->seid, &bw_config, NULL);
- if (ret) {
- PMD_INIT_LOG(ERR,
-"couldn't get PF vsi bw config, err %s aq_err %s\n",
-i40e_stat_str(hw, ret),
-i40e_aq_str(hw, hw->aq.asq_last_status));
- return ret;
- }
-
- /* Get the VSI level BW configuration per TC */
- ret = i40e_aq_query_vsi_ets_sla_config(h
[dpdk-dev] Mellanox dpdk issues
Let us check and get back to you. Gilad Berman | Staff System Engineer | Business Development | Mellanox Technologies Ltd. Work: +972 52 2554262| 6 Ha'Barzel St. Tel Aviv 6971010, Israel -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sotiris Salloumis Sent: Friday, November 20, 2015 7:35 PM To: dev at dpdk.org Subject: [dpdk-dev] Mellanox dpdk issues Hi all, I'm trying to build DPDK for Mellanox ( using MLNX_DPDK-2.1_1.1 ) but I get the following error following the guidelines i.e. make install T=x86_64-native-linuxapp-gcc == Build lib/librte_eal/linuxapp/igb_uio make[8]: *** /lib/modules/3.12.28-4-default/build: No such file or directory. Stop. /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.module.mk:79: recipe for target 'igb_uio.ko' failed make[7]: *** [igb_uio.ko] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 'igb_uio' failed make[6]: *** [igb_uio] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 'linuxapp' failed make[5]: *** [linuxapp] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 'librte_eal' failed make[4]: *** [librte_eal] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkbuild.mk:93: recipe for target 'lib' failed make[3]: *** [lib] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:124: recipe for target 'all' failed make[2]: *** [all] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkinstall.mk:58: recipe for target 'x86_64-native-linuxapp-gcc_install' failed make[1]: *** [x86_64-native-linuxapp-gcc_install] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:102: recipe for target 'install' failed make: *** [install] Error 2 The environment is SLES12 - Linux linux-okj7 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux - 3.12.28-4-default >From Mellanox point of view the only difference I see is related with firmware >version Performing Adapter Device Self Test Number of CAs Detected . 1 PCI Device Check ... PASS Kernel Arch x86_64 Host Driver Version MLNX_OFED_LINUX-3.1-1.0.3 (OFED-3.1-1.0.3): 3.12.28-4-default Host Driver RPM Check .. PASS Firmware on CA #0 NIC .. v2.35.5130 Firmware Check on CA #0 (NIC) .. PASS NOTE: The found fw version is higher than the fw included in this package (v2.35.5100) Host Driver Initialization . PASS Number of CA Ports Active .. 2 Port State of Port #1 on CA #0 (NIC). UP 1X QDR (Ethernet) Port State of Port #2 on CA #0 (NIC). UP 1X QDR (Ethernet) Error Counter Check on CA #0 (NIC).. NA (Eth ports) Kernel Syslog Check PASS Node GUID on CA #0 (NIC) ... a0:1d:48:03:00:b5:a6:17 -- DONE - Any hints? Thanks Sotiris
[dpdk-dev] [PATCH v3] i40e: fix BW info update if no dcb enabled
If DCB is not enabled, the BW info is not stored for VSI. This
patch fixes this issue by merging functions i40e_vsi_dump_bw_config
and i40e_vsi_get_bw_info together.
Fixes: c8b9a3e3fe1b (i40e: support DCB mode)
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 116 +
drivers/net/i40e/i40e_ethdev.h | 12 ++---
2 files changed, 42 insertions(+), 86 deletions(-)
v2 changes:
- correct the value used in debug log.
v3 changes:
- change the function's return value from int to enum.
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2c51a0b..f5a8f37 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3789,14 +3789,22 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
return i40e_vsi_add_mac(vsi, &filter);
}
-static int
-i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
+#define I40E_3_BIT_MASK 0x7
+/*
+ * i40e_vsi_get_bw_config - Query VSI BW Information
+ * @vsi: the VSI to be queried
+ *
+ * Returns 0 on success, negative value on failure
+ */
+static enum i40e_status_code
+i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
{
struct i40e_aqc_query_vsi_bw_config_resp bw_config;
struct i40e_aqc_query_vsi_ets_sla_config_resp ets_sla_config;
struct i40e_hw *hw = &vsi->adapter->hw;
i40e_status ret;
int i;
+ uint32_t bw_max;
memset(&bw_config, 0, sizeof(bw_config));
ret = i40e_aq_query_vsi_bw_config(hw, vsi->seid, &bw_config, NULL);
@@ -3815,20 +3823,32 @@ i40e_vsi_dump_bw_config(struct i40e_vsi *vsi)
return ret;
}
- /* Not store the info yet, just print out */
- PMD_DRV_LOG(INFO, "VSI bw limit:%u", bw_config.port_bw_limit);
- PMD_DRV_LOG(INFO, "VSI max_bw:%u", bw_config.max_bw);
+ /* store and print out BW info */
+ vsi->bw_info.bw_limit = rte_le_to_cpu_16(bw_config.port_bw_limit);
+ vsi->bw_info.bw_max = bw_config.max_bw;
+ PMD_DRV_LOG(DEBUG, "VSI bw limit:%u", vsi->bw_info.bw_limit);
+ PMD_DRV_LOG(DEBUG, "VSI max_bw:%u", vsi->bw_info.bw_max);
+ bw_max = rte_le_to_cpu_16(ets_sla_config.tc_bw_max[0]) |
+ (rte_le_to_cpu_16(ets_sla_config.tc_bw_max[1]) <<
+I40E_16_BIT_WIDTH);
for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
- PMD_DRV_LOG(INFO, "\tVSI TC%u:share credits %u", i,
- ets_sla_config.share_credits[i]);
- PMD_DRV_LOG(INFO, "\tVSI TC%u:credits %u", i,
- rte_le_to_cpu_16(ets_sla_config.credits[i]));
- PMD_DRV_LOG(INFO, "\tVSI TC%u: max credits: %u", i,
- rte_le_to_cpu_16(ets_sla_config.credits[i / 4]) >>
- (i * 4));
+ vsi->bw_info.bw_ets_share_credits[i] =
+ ets_sla_config.share_credits[i];
+ vsi->bw_info.bw_ets_credits[i] =
+ rte_le_to_cpu_16(ets_sla_config.credits[i]);
+ /* 4 bits per TC, 4th bit is reserved */
+ vsi->bw_info.bw_ets_max[i] =
+ (uint8_t)((bw_max >> (i * I40E_4_BIT_WIDTH)) &
+ I40E_3_BIT_MASK);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u:share credits %u", i,
+ vsi->bw_info.bw_ets_share_credits[i]);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u:credits %u", i,
+ vsi->bw_info.bw_ets_credits[i]);
+ PMD_DRV_LOG(DEBUG, "\tVSI TC%u: max credits: %u", i,
+ vsi->bw_info.bw_ets_max[i]);
}
- return 0;
+ return I40E_SUCCESS;
}
/* Setup a VSI */
@@ -4154,7 +4174,7 @@ i40e_vsi_setup(struct i40e_pf *pf,
}
/* Get VSI BW information */
- i40e_vsi_dump_bw_config(vsi);
+ i40e_vsi_get_bw_config(vsi);
return vsi;
fail_msix_alloc:
i40e_res_pool_free(&pf->msix_pool,vsi->msix_intr);
@@ -8081,70 +8101,6 @@ i40e_parse_dcb_configure(struct rte_eth_dev *dev,
return 0;
}
-/*
- * i40e_vsi_get_bw_info - Query VSI BW Information
- * @vsi: the VSI being queried
- *
- * Returns 0 on success, negative value on failure
- */
-static enum i40e_status_code
-i40e_vsi_get_bw_info(struct i40e_vsi *vsi)
-{
- struct i40e_aqc_query_vsi_ets_sla_config_resp bw_ets_config = {0};
- struct i40e_aqc_query_vsi_bw_config_resp bw_config = {0};
- struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
- enum i40e_status_code ret;
- int i;
- uint32_t tc_bw_max;
-
- /* Get the VSI level BW configuration */
- ret = i40e_aq_query_vsi_bw_config(hw, vsi->seid, &bw_config, NULL);
- if (ret) {
- PMD_INIT_LOG(ERR,
-"couldn't get PF vsi bw config, err %s aq_err %s\n",
-i40e_stat_str(hw, ret),
-i40e_aq_str(hw, hw->aq.asq_last_stat
[dpdk-dev] Mellanox dpdk issues
Hi Sotiris, You can disable compilation of igb_uio, this module is not needed for Mellanox PMD. Let me know if you have any question Best Regards, Olga -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gilad Berman Sent: Sunday, November 22, 2015 1:30 PM To: Sotiris Salloumis ; dev at dpdk.org Subject: Re: [dpdk-dev] Mellanox dpdk issues Let us check and get back to you. Gilad Berman | Staff System Engineer | Business Development | Mellanox Technologies Ltd. Work: +972 52 2554262| 6 Ha'Barzel St. Tel Aviv 6971010, Israel -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sotiris Salloumis Sent: Friday, November 20, 2015 7:35 PM To: dev at dpdk.org Subject: [dpdk-dev] Mellanox dpdk issues Hi all, I'm trying to build DPDK for Mellanox ( using MLNX_DPDK-2.1_1.1 ) but I get the following error following the guidelines i.e. make install T=x86_64-native-linuxapp-gcc == Build lib/librte_eal/linuxapp/igb_uio make[8]: *** /lib/modules/3.12.28-4-default/build: No such file or directory. Stop. /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.module.mk:79: recipe for target 'igb_uio.ko' failed make[7]: *** [igb_uio.ko] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 'igb_uio' failed make[6]: *** [igb_uio] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 'linuxapp' failed make[5]: *** [linuxapp] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.subdir.mk:61: recipe for target 'librte_eal' failed make[4]: *** [librte_eal] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkbuild.mk:93: recipe for target 'lib' failed make[3]: *** [lib] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:124: recipe for target 'all' failed make[2]: *** [all] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkinstall.mk:58: recipe for target 'x86_64-native-linuxapp-gcc_install' failed make[1]: *** [x86_64-native-linuxapp-gcc_install] Error 2 /root/Downloads/MLNX_DPDK-2.1_1.1/mk/rte.sdkroot.mk:102: recipe for target 'install' failed make: *** [install] Error 2 The environment is SLES12 - Linux linux-okj7 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux - 3.12.28-4-default >From Mellanox point of view the only difference I see is related with firmware >version Performing Adapter Device Self Test Number of CAs Detected . 1 PCI Device Check ... PASS Kernel Arch x86_64 Host Driver Version MLNX_OFED_LINUX-3.1-1.0.3 (OFED-3.1-1.0.3): 3.12.28-4-default Host Driver RPM Check .. PASS Firmware on CA #0 NIC .. v2.35.5130 Firmware Check on CA #0 (NIC) .. PASS NOTE: The found fw version is higher than the fw included in this package (v2.35.5100) Host Driver Initialization . PASS Number of CA Ports Active .. 2 Port State of Port #1 on CA #0 (NIC). UP 1X QDR (Ethernet) Port State of Port #2 on CA #0 (NIC). UP 1X QDR (Ethernet) Error Counter Check on CA #0 (NIC).. NA (Eth ports) Kernel Syslog Check PASS Node GUID on CA #0 (NIC) ... a0:1d:48:03:00:b5:a6:17 -- DONE - Any hints? Thanks Sotiris
[dpdk-dev] [PATCH v3] i40e: fix BW info update if no dcb enabled
> -Original Message- > From: Wu, Jingjing > Sent: Sunday, November 22, 2015 8:35 PM > To: dev at dpdk.org > Cc: Wu, Jingjing; Zhang, Helin > Subject: [PATCH v3] i40e: fix BW info update if no dcb enabled > > If DCB is not enabled, the BW info is not stored for VSI. This patch fixes > this > issue by merging functions i40e_vsi_dump_bw_config and > i40e_vsi_get_bw_info together. > > Fixes: c8b9a3e3fe1b (i40e: support DCB mode) > > Signed-off-by: Jingjing Wu Acked-by: Helin Zhang Thanks for the fix, it makes things clearer and simpler.
[dpdk-dev] difficulty w/ RTE_NEXT_ABI
2015-11-21 19:25, Matthew Hall: > On Sat, Nov 21, 2015 at 11:44:20AM +0100, Thomas Monjalon wrote: > > The new mbuf provides packet type instead of flags. > > So the processing in this function is changed and the variable name is > > different to reflect this. > > But the data type of the variable is the same, and this is an internal > always_inline function. It is an example application using a mbuf feature which changes depending of CONFIG_RTE_NEXT_ABI. The ABI is in the mbuf library not in the app. The header of the app function is changed only for the variable name because the semantic is changed. > So again I am confused what advantage we got from RTE_NEXT_ABI here, and how > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a > binary variable. I don't understand what is not clear here. > This doesn't really answer the bigger question about the reasoning. Probably because you don't ask clearly your question. Please check the code and your question again. Maybe that this reading may help: doc/guides/contributing/versioning.rst
[dpdk-dev] difficulty w/ RTE_NEXT_ABI
On Sun, Nov 22, 2015 at 09:59:30PM +0100, Thomas Monjalon wrote: > > So again I am confused what advantage we got from RTE_NEXT_ABI here, and > > how > > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a > > binary variable. > > I don't understand what is not clear here. OK. Let me restate it. I was starting from an assumption that the purpose of RTE_NEXT_ABI was to allow ABI changes. In most projects I worked on, a renaming of a variable when the data type is unchanged does not count as an ABI change. So it seems like this is different from the usual definition. Secondly, if one is making an ABI change, like I was, to some code which was already changed once using RTE_NEXT_ABI, which part of the code do you change? Do you make a third copy different from the first two copies? If you make a third copy, but RTE_NEXT_ABI is binary (i.e. it has two values, on and off) then what labeling do you apply to the third copy? If you don't make a third copy, I am assuming you edit the copy marked with RTE_NEXT_ABI. But then what happens to a downstream user who wants to have RTE_NEXT_ABI with the first ABI change, and not your second ABI change? Can you see what I am trying to ask now? Matthew.
[dpdk-dev] missing __rte_deprecated on rte_eth_stats.imcasts ?
I was reading through the deprecations in rte_eth_stats to see if I could fix the pktgen. Of course many fields were marked with __rte_deprecated . However I found this one field which said deprecated in its comment, but it lacked __rte_deprecated . Is the comment wrong, or is the field definition wrong, or did I miss something? uint64_t imcasts; /**< Deprecated; Total number of multicast received packets. */ Matthew.
[dpdk-dev] [PATCH 0/2] Reduce DPDK initialization time
This patch aims to reduce DPDK initialization time, which is important in cases such as micro service. Changes are: 1. Reduce timer initialization time 2. Remove unnecessary hugepage zero-filling operations With this patch: 1. Timer initialization time can be reduced by 4/10 second 2. Memory initialization time can be reduced nearly by half The 2nd topic has been brought up before in this thread: http://dpdk.org/dev/patchwork/patch/4219/ -- Changes in v1: 1. Use macro in sleep time initialization 2. Update commit message according to code change -- Changes in RFC v2: 1. Use MAP_POPULATE flag to populate page tables 2. Add comments to avoid future misunderstanding Zhihong Wang (2): lib/librte_eal: Reduce timer initialization time lib/librte_eal: Remove unnecessary hugepage zero-filling lib/librte_eal/linuxapp/eal/eal_memory.c | 20 ++-- lib/librte_eal/linuxapp/eal/eal_timer.c | 2 +- 2 files changed, 7 insertions(+), 15 deletions(-) -- 2.5.0
[dpdk-dev] [PATCH 1/2] lib/librte_eal: Reduce timer initialization time
Changing from 1/2 second to 1/10 doesn't compromise the precision, and a 4/10
second is worth saving.
Signed-off-by: Zhihong Wang
---
lib/librte_eal/linuxapp/eal/eal_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_timer.c
b/lib/librte_eal/linuxapp/eal/eal_timer.c
index e0642de..b40afa0 100644
--- a/lib/librte_eal/linuxapp/eal/eal_timer.c
+++ b/lib/librte_eal/linuxapp/eal/eal_timer.c
@@ -271,7 +271,7 @@ get_tsc_freq(void)
#ifdef CLOCK_MONOTONIC_RAW
#define NS_PER_SEC 1E9
- struct timespec sleeptime = {.tv_nsec = 5E8 }; /* 1/2 second */
+ struct timespec sleeptime = {.tv_nsec = NS_PER_SEC / 10 }; /* 1/10
second */
struct timespec t_start, t_end;
uint64_t tsc_hz;
--
2.5.0
[dpdk-dev] [PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
The kernel fills new allocated (huge) pages with zeros.
DPDK just has to populate page tables to trigger the allocation.
Signed-off-by: Zhihong Wang
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 0de75cd..21a5146 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -399,8 +399,10 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
return -1;
}
+ /* map the segment, and populate page tables,
+* the kernel fills this segment with zeros */
virtaddr = mmap(vma_addr, hugepage_sz, PROT_READ | PROT_WRITE,
- MAP_SHARED, fd, 0);
+ MAP_SHARED | MAP_POPULATE, fd, 0);
if (virtaddr == MAP_FAILED) {
RTE_LOG(ERR, EAL, "%s(): mmap failed: %s\n", __func__,
strerror(errno));
@@ -410,7 +412,6 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
if (orig) {
hugepg_tbl[i].orig_va = virtaddr;
- memset(virtaddr, 0, hugepage_sz);
}
else {
hugepg_tbl[i].final_va = virtaddr;
@@ -529,22 +530,16 @@ remap_all_hugepages(struct hugepage_file *hugepg_tbl,
struct hugepage_info *hpi)
old_addr = vma_addr;
- /* map new, bigger segment */
+ /* map new, bigger segment, and populate page tables,
+* the kernel fills this segment with zeros */
vma_addr = mmap(vma_addr, total_size,
- PROT_READ | PROT_WRITE, MAP_SHARED, fd,
0);
+ PROT_READ | PROT_WRITE, MAP_SHARED |
MAP_POPULATE, fd, 0);
if (vma_addr == MAP_FAILED || vma_addr != old_addr) {
RTE_LOG(ERR, EAL, "%s(): mmap failed: %s\n",
__func__, strerror(errno));
close(fd);
return -1;
}
-
- /* touch the page. this is needed because kernel
postpones mapping
-* creation until the first page fault. with this, we
pin down
-* the page and it is marked as used and gets into
process' pagemap.
-*/
- for (offset = 0; offset < total_size; offset +=
hugepage_sz)
- *((volatile uint8_t*) RTE_PTR_ADD(vma_addr,
offset));
}
/* set shared flock on the file. */
@@ -592,9 +587,6 @@ remap_all_hugepages(struct hugepage_file *hugepg_tbl,
struct hugepage_info *hpi)
}
}
- /* zero out the whole segment */
- memset(hugepg_tbl[page_idx].final_va, 0, total_size);
-
page_idx++;
}
--
2.5.0
[dpdk-dev] [PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
On Sun, 22 Nov 2015 14:13:35 -0500
Zhihong Wang wrote:
> The kernel fills new allocated (huge) pages with zeros.
> DPDK just has to populate page tables to trigger the allocation.
>
> Signed-off-by: Zhihong Wang
> ---
> lib/librte_eal/linuxapp/eal/eal_memory.c | 20 ++--
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index 0de75cd..21a5146 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -399,8 +399,10 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
> return -1;
> }
>
> + /* map the segment, and populate page tables,
> + * the kernel fills this segment with zeros */
> virtaddr = mmap(vma_addr, hugepage_sz, PROT_READ | PROT_WRITE,
> - MAP_SHARED, fd, 0);
> + MAP_SHARED | MAP_POPULATE, fd, 0);
> if (virtaddr == MAP_FAILED) {
> RTE_LOG(ERR, EAL, "%s(): mmap failed: %s\n", __func__,
> strerror(errno));
> @@ -410,7 +412,6 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
>
> if (orig) {
> hugepg_tbl[i].orig_va = virtaddr;
> - memset(virtaddr, 0, hugepage_sz);
> }
> else {
> hugepg_tbl[i].final_va = virtaddr;
> @@ -529,22 +530,16 @@ remap_all_hugepages(struct hugepage_file *hugepg_tbl,
> struct hugepage_info *hpi)
>
> old_addr = vma_addr;
>
> - /* map new, bigger segment */
> + /* map new, bigger segment, and populate page tables,
> + * the kernel fills this segment with zeros */
> vma_addr = mmap(vma_addr, total_size,
> - PROT_READ | PROT_WRITE, MAP_SHARED, fd,
> 0);
> + PROT_READ | PROT_WRITE, MAP_SHARED |
> MAP_POPULATE, fd, 0);
>
> if (vma_addr == MAP_FAILED || vma_addr != old_addr) {
> RTE_LOG(ERR, EAL, "%s(): mmap failed: %s\n",
> __func__, strerror(errno));
> close(fd);
> return -1;
> }
> -
> - /* touch the page. this is needed because kernel
> postpones mapping
> - * creation until the first page fault. with this, we
> pin down
> - * the page and it is marked as used and gets into
> process' pagemap.
> - */
> - for (offset = 0; offset < total_size; offset +=
> hugepage_sz)
> - *((volatile uint8_t*) RTE_PTR_ADD(vma_addr,
> offset));
> }
>
> /* set shared flock on the file. */
> @@ -592,9 +587,6 @@ remap_all_hugepages(struct hugepage_file *hugepg_tbl,
> struct hugepage_info *hpi)
> }
> }
>
> - /* zero out the whole segment */
> - memset(hugepg_tbl[page_idx].final_va, 0, total_size);
> -
> page_idx++;
> }
>
Nice, especially on slow machines or with large memory.
Acked-by: Stephen Hemminger
[dpdk-dev] difficulty w/ RTE_NEXT_ABI
On Mon, Nov 23, 2015 at 01:13:32AM +0100, Thomas Monjalon wrote: > If your change is sent upstream, you must rely on the new ABI because the old > one > will be removed when your change will be integrated. > If it is a local change, it depends on which ABI you want to use. I submitted separately to Bruce & Co. It is for LPM field expansion. My question what to do came up in the context of a rebase to master. > Yes. Hope my detailed answer is enough. Thanks. It is less confusing now. Matthew.
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
On Mon, 23 Nov 2015 03:46:31 + "Xie, Huawei" wrote: > > > > Why cannot we rely on the kernel zeroing the memory ? > > If that behavior were to change, then we can zero out the memory > > ourselves. > It is undocumented kernel behavior. My opinion is if not a big burden, > zero out the needed memory ourselves, otherwise resort to this kernel > behavior. Really, I think it is more an oversight of missing documentation, the kernel has always (and will continue) to zero out memory that is given to a process. If it didn't it would be a massive security hole.
[dpdk-dev] [PATCH] pktgen-stats.c: remove stats deprecated upstream
Signed-off-by: Matthew Hall --- app/pktgen-stats.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/app/pktgen-stats.c b/app/pktgen-stats.c index f1de4d7..f552ac2 100644 --- a/app/pktgen-stats.c +++ b/app/pktgen-stats.c @@ -305,8 +305,6 @@ pktgen_page_stats(void) pktgen.cumm_rate_totals.oerrors += info->rate_stats.oerrors; pktgen.cumm_rate_totals.imissed += info->rate_stats.imissed; -pktgen.cumm_rate_totals.ibadcrc += info->rate_stats.ibadcrc; -pktgen.cumm_rate_totals.ibadlen += info->rate_stats.ibadlen; pktgen.cumm_rate_totals.imcasts += info->rate_stats.imcasts; pktgen.cumm_rate_totals.rx_nombuf += info->rate_stats.rx_nombuf; @@ -344,13 +342,8 @@ pktgen_page_stats(void) wr_scrn_printf(row++, col, "%*s", COLUMN_WIDTH_1, buff); snprintf(buff, sizeof(buff), "%lu/%lu", info->tx_pps, info->tx_cycles); wr_scrn_printf(row++, col, "%*s", COLUMN_WIDTH_1, buff); - snprintf(buff, sizeof(buff), "%lu", info->stats.imissed); wr_scrn_printf(row++, col, "%*s", COLUMN_WIDTH_1, buff); - snprintf(buff, sizeof(buff), "%lu", info->stats.ibadcrc); - wr_scrn_printf(row++, col, "%*s", COLUMN_WIDTH_1, buff); - snprintf(buff, sizeof(buff), "%lu", info->stats.ibadlen); - wr_scrn_printf(row++, col, "%*s", COLUMN_WIDTH_1, buff); snprintf(buff, sizeof(buff), "%lu", info->stats.imcasts); wr_scrn_printf(row++, col, "%*s", COLUMN_WIDTH_1, buff); snprintf(buff, sizeof(buff), "%lu", info->stats.rx_nombuf); @@ -420,8 +413,6 @@ pktgen_process_stats(__attribute__((unused)) struct rte_timer *tim, __attribute_ stats.oerrors -= info->init_stats.oerrors; stats.imissed += info->init_stats.imissed; -stats.ibadcrc += info->init_stats.ibadcrc; -stats.ibadlen += info->init_stats.ibadlen; stats.imcasts += info->init_stats.imcasts; stats.rx_nombuf += info->init_stats.rx_nombuf; @@ -433,8 +424,6 @@ pktgen_process_stats(__attribute__((unused)) struct rte_timer *tim, __attribute_ info->rate_stats.oerrors= stats.oerrors - info->port_stats.oerrors; info->rate_stats.imissed += stats.imissed - info->init_stats.imissed; -info->rate_stats.ibadcrc += stats.ibadcrc - info->init_stats.ibadcrc; -info->rate_stats.ibadlen += stats.ibadlen - info->init_stats.ibadlen; info->rate_stats.imcasts += stats.imcasts - info->init_stats.imcasts; info->rate_stats.rx_nombuf += stats.rx_nombuf - info->init_stats.rx_nombuf; -- 2.5.0
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
On Mon, 23 Nov 2015 05:05:21 + "Xie, Huawei" wrote: > On 11/23/2015 12:07 PM, Stephen Hemminger wrote: > > On Mon, 23 Nov 2015 03:46:31 + > > "Xie, Huawei" wrote: > > > >>> Why cannot we rely on the kernel zeroing the memory ? > >>> If that behavior were to change, then we can zero out the memory > >>> ourselves. > >> It is undocumented kernel behavior. My opinion is if not a big burden, > >> zero out the needed memory ourselves, otherwise resort to this kernel > >> behavior. > > Really, I think it is more an oversight of missing documentation, > > the kernel has always (and will continue) to zero out memory that is given > > to a process. If it didn't it would be a massive security hole. > Agree. I believe this behavior will not change in future. For the > security issue, kernel could also set all bits like to 1. Just wonder if > this is best practice and whether there are other user space programs > rely on this behavior. > Glibc almost certainly depends on this, because heap is grown by mmaping addtional memory.
