[dpdk-dev] [PATCH 7/7] app/testpmd: rework for displaying different size of RX descriptors

[Zhang, Helin]

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Friday, June 20, 2014 10:35 PM
To: Zhang, Helin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 7/7] app/testpmd: rework for displaying 
different size of RX descriptors

2014-06-20 14:14, Helin Zhang:
> i40e supports 16 and 32 bytes RX descriptors which can be configured.
> It needs to check the driver type and the configuration to determine 
> if 16 or 32 bytes RX descriptors is being used, for reading and 
> displaying the different sizes of RX descriptors.
[...]
> + if (strstr(dev_info.driver_name, "i40e") != NULL) { /* i40e */ 
> +#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC

Do we need to handle i40e case if RTE_LIBRTE_I40E_16BYTE_RX_DESC is defined?

[simplified diff follows]
>  #else
> + struct igb_ring_desc_16_bytes *ring =
> + (struct igb_ring_desc_16_bytes *)ring_mz->addr;
>  
> + ring_rxd_display_dword(rte_le_to_cpu_64(\
> + ring[desc_id].lo_dword));
> + ring_rxd_display_dword(rte_le_to_cpu_64(\
> + ring[desc_id].hi_dword));
>  #endif
> + } else { /* not i40e */
> + struct igb_ring_desc_16_bytes *ring =
> + (struct igb_ring_desc_16_bytes *)ring_mz->addr;
> +
> + ring_rxd_display_dword(rte_le_to_cpu_64(\
> + ring[desc_id].lo_dword));
> + ring_rxd_display_dword(rte_le_to_cpu_64(\
> + ring[desc_id].hi_dword));
> + }

You could factorize these 2 cases.

--
Thomas


Hi Thomas

As RX descriptor size can vary in i40e only, and for other PMD, 
RTE_LIBRTE_I40E_16BYTE_RX_DESC will never be defined, we need to handle all 
possibilities.
Yes, I can rework the changes and let it be more graceful. Thanks!

Regards,
Helin

[dpdk-dev] [PATCH 3/7] i40e: ignore the failure of updating default filter settings

[Zhang, Helin]

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Friday, June 20, 2014 10:16 PM
To: Zhang, Helin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 3/7] i40e: ignore the failure of updating 
default filter settings

2014-06-20 14:14, Helin Zhang:
> The failure of updating the default filter setting should be ignored. 
> The updating is to change the default vlan filter behaviours 
> configured by firmware to expected.
> The failure happens on the firmware version of 4.2.2, while doesn't 
> happen on previous versions, as the default settings of firmware 
> changed.
[...]
>   ret = i40e_update_default_filter_setting(vsi);
> - if (ret != I40E_SUCCESS) {
> - PMD_DRV_LOG(ERR, "Failed to remove default "
> - "filter setting\n");
> - goto fail_msix_alloc;
> - }
> - }
> - else if (type == I40E_VSI_SRIOV) {
> + if (ret != I40E_SUCCESS)
> + PMD_DRV_LOG(ERR, "Failure of removing default filter "
> + "setting can be ignored\n");
> + /**
> +  * The failure of updating default filter setting
> +  * can be ignored
> +  */
> + } else if (type == I40E_VSI_SRIOV) {

The log is not clear and the log message doesn't include firmware explanation. 
Please reword.

By the way, there is already a log message in the function:
PMD_DRV_LOG(WARNING, "Failed to remove default [mac,vlan] config\n");
http://dpdk.org/browse/dpdk/commit/?id=9d7d8513b587d32b8f66

Will we see these error messages each time we configure an i40e device?
I think it's strange to have a log message saying it can be ignored.
Can it be a real error in some cases?

--
Thomas



Hi Thomas

For recently firmware 4.2.2, the removing default macvlan filter will always 
fail during initialization. It is not an error.
For old firmware versions, the firmwares load a default macvlan filter which 
has wrong configurations, it needs to remove the default one and reload a 
macvlan filter with correct configurations.

So the return value at that moment should be ignored. I will write more 
detailed annotations to describe the issue and why we need it, and delete logs 
to prevent confusing users.

Regards,
Helin

[dpdk-dev] [PATCH 2/7] i40evf: support configuring crc stripping hw offload

[Zhang, Helin]

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Friday, June 20, 2014 10:08 PM
To: Zhang, Helin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/7] i40evf: support configuring crc stripping 
hw offload

Hi Helin,

2014-06-20 14:14, Helin Zhang:
> In VF driver, crc stripping hw offload is enabled or not, according to 
> the configurations in config file.
> 
> Signed-off-by: Helin Zhang 
> Acked-by: Cunming Liang 
> Acked-by: Jing Chen 
[...]
>  static int
> -i40evf_dev_configure(__rte_unused struct rte_eth_dev *dev)
> +i40evf_dev_configure(struct rte_eth_dev *dev)
>  {
> + struct rte_eth_conf* conf = &dev->data->dev_conf;
> +
> +#ifdef RTE_LIBRTE_I40E_PF_DISABLE_STRIP_CRC
> + if (conf->rxmode.hw_strip_crc) {
> + conf->rxmode.hw_strip_crc = 0;
> + PMD_DRV_LOG(INFO, "VF can not enable hw CRC stripping\n");
> + }
> +#else
> + if (!conf->rxmode.hw_strip_crc) {
> + conf->rxmode.hw_strip_crc = 1;
> + PMD_DRV_LOG(INFO, "VF can not disable hw CRC stripping\n"); } 
> +#endif
> +
>   return 0;
>  }

Please, I don't understand why CRC stripping must be configured at build time.
I understand VF capability depends of the PF configuration, but we should be 
able to configure it at run time.

--
Thomas



Hi Thomas

This solution is the same as what we did in ixgbe. As you know most of VF 
functionalities are controlled by PF.
If the configuration is set for global, VF driver cannot ask for change, as the 
change will impact PF functionality.
If the configuration can be set for PF/VF function separately, VF driver can 
change it directly or ask PF to change according to the hardware implementation.

Let's skip the VF CRC change for i40e of 1.7.0-rc2 at this moment, and I will 
investigate more and send separate patches later for that.

Regards,
Helin

[dpdk-dev] [PATCH v3 2/7] ethdev: add autoneg parameter in flow ctrl accessors

[Liu, Jijiang]

Hi David,

There was an error when we used the following test command to test latest 
master branch for 10G NIC flow control 
test command: 
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4-- -i --burst=1 --txpt=32 
--txht=8 --txwt=0 --txfreet=0 --rxfreet=64 --mbcache=250 --portmask=f 
testpmd> set flow_ctrl rx off tx off 300 50 10 1 mac_ctrl_frame_fwd on 0 
bad flow contrl parameter, return code = -95  

And the reason is that autoneg check failed in ixgbe_flow_ctrl_set() function. 
if (fc_conf->autoneg != !hw->fc.disable_fc_autoneg)
return -ENOTSUP;  

Thanks
Jijiang Liu

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Marchand
Sent: Wednesday, June 18, 2014 2:09 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v3 2/7] ethdev: add autoneg parameter in flow ctrl 
accessors

Add autoneg field in flow control parameters.
This makes it easier to understand why changing some parameters does not always 
have the expected result.

Changing autoneg is not supported at the moment.

Signed-off-by: David Marchand 
---
 lib/librte_ether/rte_ethdev.h   |1 +
 lib/librte_pmd_e1000/em_ethdev.c|3 +++
 lib/librte_pmd_e1000/igb_ethdev.c   |3 +++
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c |3 +++
 4 files changed, 10 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h 
index 1e0564d..a410afd 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -649,6 +649,7 @@ struct rte_eth_fc_conf {
uint16_t send_xon;/**< Is XON frame need be sent */
enum rte_eth_fc_mode mode;  /**< Link flow control mode */
uint8_t mac_ctrl_frame_fwd; /**< Forward MAC control frames */
+   uint8_t autoneg;  /**< Use Pause autoneg */
 };

 /**
diff --git a/lib/librte_pmd_e1000/em_ethdev.c b/lib/librte_pmd_e1000/em_ethdev.c
index 58efcdf..7913ff0 100644
--- a/lib/librte_pmd_e1000/em_ethdev.c
+++ b/lib/librte_pmd_e1000/em_ethdev.c
@@ -1378,6 +1378,7 @@ eth_em_flow_ctrl_get(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
fc_conf->high_water = hw->fc.high_water;
fc_conf->low_water = hw->fc.low_water;
fc_conf->send_xon = hw->fc.send_xon;
+   fc_conf->autoneg = hw->mac.autoneg;

/*
 * Return rx_pause and tx_pause status according to actual setting of 
@@ -1422,6 +1423,8 @@ eth_em_flow_ctrl_set(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
uint32_t rctl;

hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   if (fc_conf->autoneg != hw->mac.autoneg)
+   return -ENOTSUP;
rx_buf_size = em_get_rx_buffer_size(hw);
PMD_INIT_LOG(DEBUG, "Rx packet buffer size = 0x%x \n", rx_buf_size);

diff --git a/lib/librte_pmd_e1000/igb_ethdev.c 
b/lib/librte_pmd_e1000/igb_ethdev.c
index 92ac4a8..c92b737 100644
--- a/lib/librte_pmd_e1000/igb_ethdev.c
+++ b/lib/librte_pmd_e1000/igb_ethdev.c
@@ -1871,6 +1871,7 @@ eth_igb_flow_ctrl_get(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
fc_conf->high_water = hw->fc.high_water;
fc_conf->low_water = hw->fc.low_water;
fc_conf->send_xon = hw->fc.send_xon;
+   fc_conf->autoneg = hw->mac.autoneg;

/*
 * Return rx_pause and tx_pause status according to actual setting of 
@@ -1915,6 +1916,8 @@ eth_igb_flow_ctrl_set(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
uint32_t rctl;

hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   if (fc_conf->autoneg != hw->mac.autoneg)
+   return -ENOTSUP;
rx_buf_size = igb_get_rx_buffer_size(hw);
PMD_INIT_LOG(DEBUG, "Rx packet buffer size = 0x%x \n", rx_buf_size);

diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index f130080..559d246 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -2309,6 +2309,7 @@ ixgbe_flow_ctrl_get(struct rte_eth_dev *dev, struct 
rte_eth_fc_conf *fc_conf)
fc_conf->high_water = hw->fc.high_water[0];
fc_conf->low_water = hw->fc.low_water[0];
fc_conf->send_xon = hw->fc.send_xon;
+   fc_conf->autoneg = !hw->fc.disable_fc_autoneg;

/*
 * Return rx_pause status according to actual setting of @@ -2360,6 
+2361,8 @@ ixgbe_flow_ctrl_set(struct rte_eth_dev *dev, struct rte_eth_fc_conf 
*fc_conf)
PMD_INIT_FUNC_TRACE();

hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   if (fc_conf->autoneg != !hw->fc.disable_fc_autoneg)
+   return -ENOTSUP;
rx_buf_size = IXGBE_READ_REG(hw, IXGBE_RXPBSIZE(0));
PMD_INIT_LOG(DEBUG, "Rx packet buffer size = 0x%x \n", rx_buf_size);

--
1.7.10.4

[dpdk-dev] [PATCH] i40e: Fix an icc compile error

[Chen Jing D(Mark)]

From: "Chen Jing D(Mark)" 

Make a cast on variable to fix the ICC compile error.

Signed-off-by: Chen Jing D(Mark) 
---
 lib/librte_pmd_i40e/i40e_ethdev_vf.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev_vf.c 
b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
index 9e86285..b9c1483 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev_vf.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
@@ -471,7 +471,7 @@ i40evf_config_vlan_offload(struct rte_eth_dev *dev,
offload.vsi_id = vf->vsi_res->vsi_id;
offload.enable_vlan_strip = enable_vlan_strip;

-   args.ops = I40E_VIRTCHNL_OP_CFG_VLAN_OFFLOAD;
+   args.ops = (enum i40e_virtchnl_ops)I40E_VIRTCHNL_OP_CFG_VLAN_OFFLOAD;
args.in_args = (uint8_t *)&offload;
args.in_args_size = sizeof(offload);
args.out_buffer = cmd_result_buffer;
@@ -502,7 +502,7 @@ i40evf_config_vlan_pvid(struct rte_eth_dev *dev,
tpid_info.vsi_id = vf->vsi_res->vsi_id;
(void)rte_memcpy(&tpid_info.info, info, sizeof(*info));

-   args.ops = I40E_VIRTCHNL_OP_CFG_VLAN_PVID;
+   args.ops = (enum i40e_virtchnl_ops)I40E_VIRTCHNL_OP_CFG_VLAN_PVID;
args.in_args = (uint8_t *)&tpid_info;
args.in_args_size = sizeof(tpid_info);
args.out_buffer = cmd_result_buffer;
-- 
1.7.7.6

[dpdk-dev] [PATCH v3 2/7] ethdev: add autoneg parameter in flow ctrl accessors

[David Marchand]

Hello,

On 06/23/2014 05:35 AM, Liu, Jijiang wrote:
> There was an error when we used the following test command to test latest 
> master branch for 10G NIC flow control
> test command:
> ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4-- -i --burst=1 --txpt=32 
> --txht=8 --txwt=0 --txfreet=0 --rxfreet=64 --mbcache=250 --portmask=f
> testpmd> set flow_ctrl rx off tx off 300 50 10 1 mac_ctrl_frame_fwd on 0
> bad flow contrl parameter, return code = -95
>
> And the reason is that autoneg check failed in ixgbe_flow_ctrl_set() function.
>   if (fc_conf->autoneg != !hw->fc.disable_fc_autoneg)
>   return -ENOTSUP;

Ok, indeed, there is a problem with the autoneg field I added.
I will try to send a fix, but I am a bit short on time (and I will be 
offline for a week starting thursday), so if you have a fix before me, 
feel free to send it.


-- 
David Marchand

[dpdk-dev] CPU does not support x86-64 instruction set

[Alex Markuze]

Hi, I'm new to DPDK and Im trying to compile on a x86 Ubuntu 14.04 VM(KVM).
And I'm getting this error:

"error: CPU you selected does not support x86-64 instruction set"

I've seen in the Archive that Jinho had this same issue last year, I'd be
glad to know how it was resolved.

Thanks
Alex.

[dpdk-dev] [PATCH v2 2/7] i40evf: remove an interface which is not used

[Helin Zhang]

i40evf_dev_atomic_read_link_status() was defined but not used.
To avoid possible warnings by some compilers, it needs to
delete the whole function.

Signed-off-by: Helin Zhang 
Acked-by: Jing Chen 
Acked-by: Cunming Liang 
---
 lib/librte_pmd_i40e/i40e_ethdev_vf.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev_vf.c 
b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
index 9e86285..4800902 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev_vf.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
@@ -883,20 +883,6 @@ static struct rte_pci_id pci_id_i40evf_map[] = {
 };

 static inline int
-i40evf_dev_atomic_read_link_status(struct rte_eth_dev *dev,
-  struct rte_eth_link *link)
-{
-   struct rte_eth_link *dst = link;
-   struct rte_eth_link *src = &(dev->data->dev_link);
-
-   if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
-   *(uint64_t *)src) == 0)
-   return -1;
-
-   return 0;
-}
-
-static inline int
 i40evf_dev_atomic_write_link_status(struct rte_eth_dev *dev,
struct rte_eth_link *link)
 {
-- 
1.8.1.4

[dpdk-dev] [PATCH v2 3/7] i40evf: fix for copying wrong size of link info

[Helin Zhang]

Fix a bug of copying wrong size of link information in the
function of i40evf_get_link_status().

Signed-off-by: Helin Zhang 
Acked-by: Jing Chen 
Acked-by: Cunming Liang 
---
 lib/librte_pmd_i40e/i40e_ethdev_vf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev_vf.c 
b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
index 4800902..081589c 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev_vf.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
@@ -871,7 +871,7 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct 
rte_eth_link *link)
}

new_link = (struct rte_eth_link *)args.out_buffer;
-   (void)rte_memcpy(link, new_link, sizeof(link));
+   (void)rte_memcpy(link, new_link, sizeof(*link));

return 0;
 }
-- 
1.8.1.4

[dpdk-dev] [PATCH v2 0/7] enhancements for i40e

[Helin Zhang]

These patches are enhancements for i40e or relevant. In detail, they include:
 * fix for getting correct RSS hash result
 * remove an interface which is not used
 * fix for copying wrong size of link info
 * fix for updating the hash lookup table of PF RSS
 * double vlan should be specifically disabled by default
 * ignore the failure of updating default macvlan filter.
 * rework for displaying different size of RX descriptors in testpmd.

Helin Zhang (7):
  i40e: fix for getting correct RSS hash result
  i40evf: remove an interface which is not used
  i40evf: fix for copying wrong size of link info
  i40e: fix for updating the hash lookup table of PF RSS
  i40e: double vlan should be specifically disabled by default
  i40e: ignore the failure of updating default macvlan filter
  app/testpmd: rework for displaying different size of RX descriptors

 app/test-pmd/config.c| 73 
 lib/librte_pmd_i40e/i40e_ethdev.c| 35 ++---
 lib/librte_pmd_i40e/i40e_ethdev_vf.c | 16 +---
 lib/librte_pmd_i40e/i40e_rxtx.c  |  4 +-
 4 files changed, 73 insertions(+), 55 deletions(-)

-- 
1.8.1.4

[dpdk-dev] [PATCH v2 5/7] i40e: double vlan should be specifically disabled by default

[Helin Zhang]

Double vlan should be specifically disabled by default during
port initialization which is expected.

Signed-off-by: Helin Zhang 
Acked-by: Jing Chen 
Acked-by: Cunming Liang 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 0d7be44..204d2cb 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -482,6 +482,10 @@ eth_i40e_dev_init(__rte_unused struct eth_driver *eth_drv,
}

vsi = pf->main_vsi;
+
+   /* Disable double vlan by default */
+   i40e_vsi_config_double_vlan(vsi, FALSE);
+
if (!vsi->max_macaddrs)
len = ETHER_ADDR_LEN;
else
-- 
1.8.1.4

[dpdk-dev] [PATCH v2 7/7] app/testpmd: rework for displaying different size of RX descriptors

[Helin Zhang]

i40e supports 16 and 32 bytes RX descriptors which can be configured.
It needs to check the driver type and the configuration to determine
if 16 or 32 bytes RX descriptors is being used, for reading and
displaying the different sizes of RX descriptors.

Signed-off-by: Helin Zhang 
Acked-by: Jing Chen 
Acked-by: Cunming Liang 
---
 app/test-pmd/config.c | 73 +--
 1 file changed, 48 insertions(+), 25 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 0023ab2..b08b006 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -581,53 +581,76 @@ union igb_ring_dword {
} words;
 };

-#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC
-struct igb_ring_desc_32B {
+struct igb_ring_desc_32_bytes {
union igb_ring_dword lo_dword;
union igb_ring_dword hi_dword;
union igb_ring_dword resv1;
union igb_ring_dword resv2;
 };
-#endif

-struct igb_ring_desc {
+struct igb_ring_desc_16_bytes {
union igb_ring_dword lo_dword;
union igb_ring_dword hi_dword;
 };

 static void
-ring_rx_descriptor_display(const struct rte_memzone *ring_mz, uint16_t desc_id)
+ring_rxd_display_dword(union igb_ring_dword dword)
 {
-#ifdef RTE_LIBRTE_I40E_16BYTE_RX_DESC
-   struct igb_ring_desc *ring;
-   struct igb_ring_desc rd;
+   printf("0x%08X - 0x%08X\n", (unsigned)dword.words.lo,
+   (unsigned)dword.words.hi);
+}

-   ring = (struct igb_ring_desc *) ring_mz->addr;
+static void
+ring_rx_descriptor_display(const struct rte_memzone *ring_mz,
+#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC
+  uint8_t port_id,
 #else
-   struct igb_ring_desc_32B *ring;
-   struct igb_ring_desc_32B rd;
+  __rte_unused uint8_t port_id,
+#endif
+  uint16_t desc_id)
+{
+   struct igb_ring_desc_16_bytes *ring =
+   (struct igb_ring_desc_16_bytes *)ring_mz->addr;
+#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC
+   struct rte_eth_dev_info dev_info;
+
+   memset(&dev_info, 0, sizeof(dev_info));
+   rte_eth_dev_info_get(port_id, &dev_info);
+   if (strstr(dev_info.driver_name, "i40e") != NULL) {
+   /* 32 bytes RX descriptor, i40e only */
+   struct igb_ring_desc_32_bytes *ring =
+   (struct igb_ring_desc_32_bytes *)ring_mz->addr;

-   ring = (struct igb_ring_desc_32B *) ring_mz->addr;
+   ring_rxd_display_dword(rte_le_to_cpu_64(\
+   ring[desc_id].lo_dword));
+   ring_rxd_display_dword(rte_le_to_cpu_64(\
+   ring[desc_id].hi_dword));
+   ring_rxd_display_dword(rte_le_to_cpu_64(\
+   ring[desc_id].resv1));
+   ring_rxd_display_dword(rte_le_to_cpu_64(\
+   ring[desc_id].resv2));
+   return;
+   }
 #endif
-   rd.lo_dword = rte_le_to_cpu_64(ring[desc_id].lo_dword);
-   rd.hi_dword = rte_le_to_cpu_64(ring[desc_id].hi_dword);
-   printf("0x%08X - 0x%08X / 0x%08X - 0x%08X\n",
-   (unsigned)rd.lo_dword.words.lo, (unsigned)rd.lo_dword.words.hi,
-   (unsigned)rd.hi_dword.words.lo, (unsigned)rd.hi_dword.words.hi);
+   /* 16 bytes RX descriptor */
+   ring_rxd_display_dword(rte_le_to_cpu_64(\
+   ring[desc_id].lo_dword));
+   ring_rxd_display_dword(rte_le_to_cpu_64(\
+   ring[desc_id].hi_dword));
 }

 static void
 ring_tx_descriptor_display(const struct rte_memzone *ring_mz, uint16_t desc_id)
 {
-   struct igb_ring_desc *ring;
-   struct igb_ring_desc rd;
+   struct igb_ring_desc_16_bytes *ring;
+   struct igb_ring_desc_16_bytes txd;

-   ring = (struct igb_ring_desc *) ring_mz->addr;
-   rd.lo_dword = rte_le_to_cpu_64(ring[desc_id].lo_dword);
-   rd.hi_dword = rte_le_to_cpu_64(ring[desc_id].hi_dword);
+   ring = (struct igb_ring_desc_16_bytes *)ring_mz->addr;
+   txd.lo_dword = rte_le_to_cpu_64(ring[desc_id].lo_dword);
+   txd.hi_dword = rte_le_to_cpu_64(ring[desc_id].hi_dword);
printf("0x%08X - 0x%08X / 0x%08X - 0x%08X\n",
-   (unsigned)rd.lo_dword.words.lo, (unsigned)rd.lo_dword.words.hi,
-   (unsigned)rd.hi_dword.words.lo, (unsigned)rd.hi_dword.words.hi);
+   (unsigned)txd.lo_dword.words.lo, 
(unsigned)txd.lo_dword.words.hi,
+   (unsigned)txd.hi_dword.words.lo, 
(unsigned)txd.hi_dword.words.hi);
 }

 void
@@ -644,7 +667,7 @@ rx_ring_desc_display(portid_t port_id, queueid_t rxq_id, 
uint16_t rxd_id)
rx_mz = ring_dma_zone_lookup("rx_ring", port_id, rxq_id);
if (rx_mz == NULL)
return;
-   ring_rx_descriptor_display(rx_mz, rxd_id);
+   ring_rx_descriptor_display(rx_mz, port_id, rxd_id);
 }

 void
-- 
1.8.1.4

[dpdk-dev] [PATCH v2 1/7] i40e: fix for getting correct RSS hash result

[Helin Zhang]

It wrongly gets the RSS hash result from the RX descriptor which
has been modified for receiving new packet. The fix is to get the
RSS hash result from the buffer which saves the RX descriptor.

Signed-off-by: Helin Zhang 
Acked-by: Jing Chen 
Acked-by: Cunming Liang 
---
 lib/librte_pmd_i40e/i40e_rxtx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 9fccbee..3a6a2d8 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -863,7 +863,7 @@ i40e_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
rxm->ol_flags = pkt_flags;
if (pkt_flags & PKT_RX_RSS_HASH)
rxm->pkt.hash.rss =
-   rte_le_to_cpu_32(rxdp->wb.qword0.hi_dword.rss);
+   rte_le_to_cpu_32(rxd.wb.qword0.hi_dword.rss);

rx_pkts[nb_rx++] = rxm;
}
@@ -1016,7 +1016,7 @@ i40e_recv_scattered_pkts(void *rx_queue,
first_seg->ol_flags = pkt_flags;
if (pkt_flags & PKT_RX_RSS_HASH)
rxm->pkt.hash.rss =
-   rte_le_to_cpu_32(rxdp->wb.qword0.hi_dword.rss);
+   rte_le_to_cpu_32(rxd.wb.qword0.hi_dword.rss);

/* Prefetch data of first segment, if configured to do so. */
rte_prefetch0(first_seg->pkt.data);
-- 
1.8.1.4

[dpdk-dev] [PATCH v2 4/7] i40e: fix for updating the hash lookup table of PF RSS

[Helin Zhang]

The bit shifting were written wrongly in '0x1 < j',
the correct one should be '0x1 << j'.

Signed-off-by: Helin Zhang 
Acked-by: Jing Chen 
Acked-by: Cunming Liang 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 1b4e822..0d7be44 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -1452,7 +1452,7 @@ i40e_dev_rss_reta_update(struct rte_eth_dev *dev,
l = I40E_READ_REG(hw, I40E_PFQF_HLUT(i >> 2));

for (j = 0, lut = 0; j < 4; j++) {
-   if (mask & (0x1 < j))
+   if (mask & (0x1 << j))
lut |= reta_conf->reta[i + j] << (8 * j);
else
lut |= l & (0xFF << (8 * j));
-- 
1.8.1.4

[dpdk-dev] [PATCH v2 6/7] i40e: ignore the failure of updating default macvlan filter

[Helin Zhang]

For NVM4.2.2 or after, the firmware has the correct configurations
and load the macvlan filter as expected. It is not needed to
Update the default macvlan filter which cannot be removed at
all during initialization.

Signed-off-by: Helin Zhang 
Acked-by: Jing Chen 
Acked-by: Cunming Liang 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 204d2cb..3311d73 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -2306,11 +2306,10 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
ret = i40e_aq_remove_macvlan(hw, vsi->seid, &def_filter, 1, NULL);
if (ret != I40E_SUCCESS) {
struct i40e_mac_filter *f;
-   PMD_DRV_LOG(WARNING, "Failed to remove default [mac,vlan] 
config\n");

-   /* Even failed to update default setting, still needs to add 
the permanent
-*  mac into mac list.
-*/
+   PMD_DRV_LOG(WARNING, "Cannot remove the default "
+   "macvlan filter\n");
+   /* It needs to add the permanent mac into mac list */
f = rte_zmalloc("macv_filter", sizeof(*f), 0);
if (f == NULL) {
PMD_DRV_LOG(ERR, "failed to allocate memory\n");
@@ -2320,6 +2319,7 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
ETH_ADDR_LEN);
TAILQ_INSERT_TAIL(&vsi->mac_list, f, next);
vsi->mac_num++;
+
return ret;
}

@@ -2516,14 +2516,19 @@ i40e_vsi_setup(struct i40e_pf *pf,

(void)rte_memcpy(pf->dev_addr.addr_bytes, hw->mac.perm_addr,
ETH_ADDR_LEN);
-   ret = i40e_update_default_filter_setting(vsi);
-   if (ret != I40E_SUCCESS) {
-   PMD_DRV_LOG(ERR, "Failed to remove default "
-   "filter setting\n");
-   goto fail_msix_alloc;
-   }
-   }
-   else if (type == I40E_VSI_SRIOV) {
+
+   /**
+* Updating default filter settings are necessary to prevent
+* reception of tagged packets.
+* Some old firmware configurations load a default macvlan
+* filter which accepts both tagged and untagged packets.
+* The updating is to use a normal filter instead if needed.
+* For NVM 4.2.2 or after, the updating is not needed anymore.
+* The firmware with correct configurations load the default
+* macvlan filter which is expected and cannot be removed.
+*/
+   i40e_update_default_filter_setting(vsi);
+   } else if (type == I40E_VSI_SRIOV) {
memset(&ctxt, 0, sizeof(ctxt));
/**
 * For other VSI, the uplink_seid equals to uplink VSI's
-- 
1.8.1.4

[dpdk-dev] CPU does not support x86-64 instruction set

[Thomas Monjalon]

Hi,

2014-06-23 15:42, Alex Markuze:
> Hi, I'm new to DPDK and Im trying to compile on a x86 Ubuntu 14.04 VM(KVM).
> And I'm getting this error:
> 
> "error: CPU you selected does not support x86-64 instruction set"

You should try "-cpu host" option of Qemu/KVM in order to have the full 
instruction set of your host.

Please confirm it's working.
-- 
Thomas

[dpdk-dev] [PATCH] i40e: Fix an icc compile error

[Thomas Monjalon]

> Make a cast on variable to fix the ICC compile error.
> 
> Signed-off-by: Chen Jing D(Mark) 

Applied for version 1.7.0.

Thanks for quick fixing.
-- 
Thomas

[dpdk-dev] [PATCH v2 7/7] app/testpmd: rework for displaying different size of RX descriptors

[Thomas Monjalon]

Hi Helin,

Thanks for this new patchset version.

2014-06-23 20:57, Helin Zhang:
> i40e supports 16 and 32 bytes RX descriptors which can be configured.
> It needs to check the driver type and the configuration to determine
> if 16 or 32 bytes RX descriptors is being used, for reading and
> displaying the different sizes of RX descriptors.
> 
> Signed-off-by: Helin Zhang 
> Acked-by: Jing Chen 
> Acked-by: Cunming Liang 

Just before applying theses patches, I checked with checkpatch.pl which warned 
me about this:

> + ring_rxd_display_dword(rte_le_to_cpu_64(\
> + ring[desc_id].lo_dword));
> + ring_rxd_display_dword(rte_le_to_cpu_64(\
> + ring[desc_id].hi_dword));
> + ring_rxd_display_dword(rte_le_to_cpu_64(\
> + ring[desc_id].resv1));
> + ring_rxd_display_dword(rte_le_to_cpu_64(\
> + ring[desc_id].resv2));

WARNING:LINE_CONTINUATIONS: Avoid unnecessary line continuations

Could you remove it please?

Thanks
-- 
Thomas

[dpdk-dev] PCIid 0x0436

[Richardson, Bruce]

I've checked the Intel Communications Chipset 89xx Series (Cave Creek) 
datasheet 
[http://www.intel.ie/content/www/ie/en/intelligent-systems/crystal-forest-server/intel-communications-chipset-89xx-series-datasheet.html],
 and 0x0436 is indeed one of the possible PCI IDs used by that product. 
However, the datasheet explicitly says that it does not need to be handled by 
the NIC drivers - compared to say, 0x0438, which does. Table 3-5 in the 
datasheet indicates what PCI IDs correspond to what connection types. The 
previous table, Table 3-4, was more confusing and seemed to indicate that the 
PCI ID was based on the Port number, but Table 3-5 clarifies things.

Regards,
/Bruce

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> Sent: Sunday, June 22, 2014 7:00 AM
> To: Gooch, Stephen (Wind River)
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] PCIid 0x0436
> 
> Hi Stephen
> 
> It seems it hasn't been supported by standard Linux driver. We just follow it.
> And what 0436 stands for? I am not quite sure about what it is.
> 
> Regards,
> Helin
> 
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Gooch, Stephen
> Sent: Saturday, June 21, 2014 6:40 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] PCIid 0x0436
> 
> Hello,
> 
> Cave Creek has PCI id of 0x0436 for port0 and 0x0438 for port1.  However only
> 0x0438 is listed in rte_pci_dev_ids.h.   Why is 0x0436 not listed?
> 
> Best Regards
> - Stephen

[dpdk-dev] Why rte_snprintf at all?

[Stephen Hemminger]

Why does rte_snprintf exist? It seems like a misunderstanding or broken
implementation of snprintf in some other C library. For standard Glibc,
I get same result from rte_snprintf and snprintf for all inputs including
boundary cases

[dpdk-dev] [PATCH v2] kni: fix compile errors on Oracle Linux6.4 and RHEL6.5

[Thomas Monjalon]

> The compile errors are copied as follows. The fixes came from
> Linux drivers of ixgbe-3.21.2 and igb-5.1.2 with modifications.
> The idea is to use self-defined functions no matter they have
> already been defined somewhere or not.
> 
> * Oracle Linux6.4
> lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h:3111:
> error: redefinition of 'ether_addr_equal'
> include/linux/etherdevice.h:180: note: previous definition
> of 'ether_addr_equal' was here
> * RHEL6.5
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3597:
> error: redefinition of 'mmd_eee_cap_to_ethtool_sup_t'
> include/linux/mdio.h:387: note: previous definition of
> 'mmd_eee_cap_to_ethtool_sup_t' was here
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3625:
> error: redefinition of 'mmd_eee_adv_to_ethtool_adv_t'
> include/linux/mdio.h:415: note: previous definition of
> 'mmd_eee_adv_to_ethtool_adv_t' was here
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3653:
> error: redefinition of 'ethtool_adv_to_mmd_eee_adv_t'
> include/linux/mdio.h:443: note: previous definition of
> 'ethtool_adv_to_mmd_eee_adv_t' was here
> 
> Signed-off-by: HELIN ZHANG 
> Acked-by: Cunming Liang 
> Tested-by: Waterman Cao 

Applied for version 1.7.0.

Thanks
-- 
Thomas

[dpdk-dev] [PATCH v3 0/2] malloc: fix malloc and free linear complexity

[Robert Sanford]

Comments on previous versions of this patch:
http://dpdk.org/ml/archives/dev/2014-May/002297.html
http://dpdk.org/ml/archives/dev/2014-June/003518.html

Additional changes from original to v3:
* Reduce the minimum-sized block that we put on a free list when
  splitting a larger block, from 192 to 64. Although memory is
  plentiful, why waste 64 and 128-byte (plus overhead) blocks?

-#define MIN_DATA_SIZE (CACHE_LINE_SIZE * 2)
+#define MIN_DATA_SIZE (CACHE_LINE_SIZE)

-   if (old_elem_size <= MALLOC_ELEM_OVERHEAD + MIN_DATA_SIZE){
+   if (old_elem_size < MALLOC_ELEM_OVERHEAD + MIN_DATA_SIZE){

-   if (elem->size - new_size > MIN_DATA_SIZE + MALLOC_ELEM_OVERHEAD){
+   if (elem->size - new_size >= MIN_DATA_SIZE + MALLOC_ELEM_OVERHEAD){

Changes from v2 to v3:
* Change the size ranges of the five free lists per heap. The first
  list will effectively contain blocks of size [64,256].

-  *   heap->free_head[0] - (0   , 2^7]
-  *   heap->free_head[1] - (2^7 , 2^9]
-  *   heap->free_head[2] - (2^9 , 2^11]
-  *   heap->free_head[3] - (2^11, 2^13]
-  *   heap->free_head[4] - (2^13, MAX_SIZE]
+  *   heap->free_head[0] - (0   , 2^8]
+  *   heap->free_head[1] - (2^8 , 2^10]
+  *   heap->free_head[2] - (2^10 ,2^12]
+  *   heap->free_head[3] - (2^12, 2^14]
+  *   heap->free_head[4] - (2^14, MAX_SIZE]

- #define MALLOC_MINSIZE_LOG2   7
+ #define MALLOC_MINSIZE_LOG2   8

* Fix typos and false assumptions in malloc unit tests. Even without
  linked-list enhancements to lib rte_malloc, malloc autotest fails
  every second (2nd) run.

[dpdk-dev] [PATCH v3 1/2] malloc: fix malloc and free linear complexity

[Robert Sanford]

Problems with lib rte_malloc:
1. Rte_malloc searches a heap's entire free list looking for the best
   fit, resulting in linear complexity.
2. Heaps store free blocks in a singly-linked list, resulting in
   linear complexity when rte_free needs to remove an adjacent block.
3. The library inserts and removes free blocks with ad hoc, in-line
   code, rather than using linked-list functions or macros.
4. The library wastes potential small blocks of size 64 and 128 bytes
   (plus overhead of 64 bytes) as padding when reusing free blocks or
   resizing allocated blocks.

This patch addresses those problems as follows:
1. Replace single free list with a handful of free lists. Each free
   list contains blocks of a specified size range, for example:
 list[0]: (0   , 2^8]
 list[1]: (2^8 , 2^10]
 list[2]: (2^10, 2^12]
 list[3]: (2^12, 2^14]
 list[4]: (2^14, MAX_SIZE]

   When allocating a block, start at the first list that can contain
   a big enough block. Search subsequent lists, if necessary.
   Terminate the search as soon as we find a block that is big enough.
2. Use doubly-linked lists, so that we can remove free blocks in
   constant time.
3. Use BSD LIST macros, as defined in sys/queue.h and the QUEUE(3)
   man page.
4. Change code to utilize small blocks of data size 64 and 128, when
   splitting larger blocks.

Signed-off-by: Robert Sanford 

---
 lib/librte_eal/common/include/rte_malloc_heap.h |6 +-
 lib/librte_malloc/malloc_elem.c |  127 +++
 lib/librte_malloc/malloc_elem.h |   17 +++-
 lib/librte_malloc/malloc_heap.c |   67 +---
 4 files changed, 131 insertions(+), 86 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_malloc_heap.h 
b/lib/librte_eal/common/include/rte_malloc_heap.h
index fc4fd0a..f727b7a 100644
--- a/lib/librte_eal/common/include/rte_malloc_heap.h
+++ b/lib/librte_eal/common/include/rte_malloc_heap.h
@@ -35,14 +35,18 @@
 #define _RTE_MALLOC_HEAP_H_

 #include 
+#include 
 #include 

+/* Number of free lists per heap, grouped by size. */
+#define RTE_HEAP_NUM_FREELISTS  5
+
 /**
  * Structure to hold malloc heap
  */
 struct malloc_heap {
rte_spinlock_t lock;
-   struct malloc_elem * volatile free_head;
+   LIST_HEAD(, malloc_elem) free_head[RTE_HEAP_NUM_FREELISTS];
unsigned mz_count;
unsigned alloc_count;
size_t total_size;
diff --git a/lib/librte_malloc/malloc_elem.c b/lib/librte_malloc/malloc_elem.c
index 172da69..75a94d0 100644
--- a/lib/librte_malloc/malloc_elem.c
+++ b/lib/librte_malloc/malloc_elem.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include 
@@ -49,7 +50,7 @@
 #include "malloc_elem.h"
 #include "malloc_heap.h"

-#define MIN_DATA_SIZE (CACHE_LINE_SIZE * 2)
+#define MIN_DATA_SIZE (CACHE_LINE_SIZE)

 /*
  * initialise a general malloc_elem header structure
@@ -60,7 +61,8 @@ malloc_elem_init(struct malloc_elem *elem,
 {
elem->heap = heap;
elem->mz = mz;
-   elem->prev = elem->next_free = NULL;
+   elem->prev = NULL;
+   memset(&elem->free_list, 0, sizeof(elem->free_list));
elem->state = ELEM_FREE;
elem->size = size;
elem->pad = 0;
@@ -125,19 +127,76 @@ split_elem(struct malloc_elem *elem, struct malloc_elem 
*split_pt)
 }

 /*
+ * Given an element size, compute its freelist index.
+ * We free an element into the freelist containing similarly-sized elements.
+ * We try to allocate elements starting with the freelist containing
+ * similarly-sized elements, and if necessary, we search freelists
+ * containing larger elements.
+ *
+ * Example element size ranges for a heap with five free lists:
+ *   heap->free_head[0] - (0   , 2^8]
+ *   heap->free_head[1] - (2^8 , 2^10]
+ *   heap->free_head[2] - (2^10 ,2^12]
+ *   heap->free_head[3] - (2^12, 2^14]
+ *   heap->free_head[4] - (2^14, MAX_SIZE]
+ */
+size_t
+malloc_elem_free_list_index(size_t size)
+{
+#define MALLOC_MINSIZE_LOG2   8
+#define MALLOC_LOG2_INCREMENT 2
+
+   size_t log2;
+   size_t index;
+
+   if (size <= (1UL << MALLOC_MINSIZE_LOG2))
+   return 0;
+
+   /* Find next power of 2 >= size. */
+   log2 = sizeof(size) * 8 - __builtin_clzl(size-1);
+
+   /* Compute freelist index, based on log2(size). */
+   index = (log2 - MALLOC_MINSIZE_LOG2 + MALLOC_LOG2_INCREMENT - 1) /
+   MALLOC_LOG2_INCREMENT;
+
+   return (index <= RTE_HEAP_NUM_FREELISTS-1?
+   index: RTE_HEAP_NUM_FREELISTS-1);
+}
+
+/*
+ * Add the specified element to its heap's free list.
+ */
+void
+malloc_elem_free_list_insert(struct malloc_elem *elem)
+{
+   size_t idx = malloc_elem_free_list_index(elem->size - 
MALLOC_ELEM_HEADER_LEN);
+
+   elem->state = ELEM_FREE;
+   LIST_INSERT_HEAD(&elem->heap->free_head[idx], elem, free_list);
+}
+
+/*
+ * Remove the specified element from its heap's free list.
+ */
+static void
+elem_free_list_remove(stru

[dpdk-dev] [PATCH v3 2/2] malloc: fix malloc and free linear complexity

[Robert Sanford]

Fix typos and false assumptions in malloc unit tests.

Without enhancements to lib rte_malloc, malloc autotest fails every
second (2nd) run. With enhancements, malloc autotest fails in
function test_multi_alloc_statistics, because we compare the wrong
sets of statistics.

Signed-off-by: Robert Sanford 

---
 app/test/test_malloc.c |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c
index 3c38383..bf27eff 100644
--- a/app/test/test_malloc.c
+++ b/app/test/test_malloc.c
@@ -66,7 +66,7 @@
  * ==
  *
  * Allocate some dynamic memory from heap (3 areas). Check that areas
- * don't overlap an that alignment constraints match. This test is
+ * don't overlap and that alignment constraints match. This test is
  * done many times on different lcores simultaneously.
  */

@@ -313,9 +313,9 @@ test_big_alloc(void)
rte_malloc_get_socket_stats(socket,&post_stats);

/* Check statistics reported are correct */
-   /* Allocation increase, cannot be the same as before big allocation */
-   if (post_stats.heap_totalsz_bytes == pre_stats.heap_totalsz_bytes) {
-   printf("Malloc statistics are incorrect - heap_totalz_bytes\n");
+   /* Allocation may increase, or may be the same as before big allocation 
*/
+   if (post_stats.heap_totalsz_bytes < pre_stats.heap_totalsz_bytes) {
+   printf("Malloc statistics are incorrect - 
heap_totalsz_bytes\n");
return -1;
}
/* Check that allocated size adds up correctly */
@@ -336,7 +336,8 @@ test_big_alloc(void)
return -1;
}
/* New blocks now available - just allocated 1 but also 1 new free */
-   if(post_stats.free_count != pre_stats.free_count ) {
+   if (post_stats.free_count != pre_stats.free_count &&
+   post_stats.free_count != pre_stats.free_count - 1) {
printf("Malloc statistics are incorrect - free_count\n");
return -1;
}
@@ -425,7 +426,7 @@ test_multi_alloc_statistics(void)
}

/* Make sure that we didn't touch our greatest chunk: 2 * 11M)  */
-   if (second_stats.greatest_free_size != pre_stats.greatest_free_size) {
+   if (post_stats.greatest_free_size != pre_stats.greatest_free_size) {
printf("Incorrect heap statistics: Greatest free size \n");
return -1;
}
@@ -1036,11 +1037,11 @@ test_malloc(void)

ret = test_multi_alloc_statistics();
if (ret < 0) {
-   printf("test_muti_alloc_statistics() failed\n");
+   printf("test_multi_alloc_statistics() failed\n");
return ret;
}
else
-   printf("test_muti_alloc_statistics() passed\n");
+   printf("test_multi_alloc_statistics() passed\n");

return 0;
 }
-- 
1.7.1

[dpdk-dev] NIC-related dpdk questions.

[Harish Patil]

Folks,
I?m a newbie going thru? dpdk. Have few quick questions.

1) Where can I find implementations of PMD of third party (non-Intel)
adapters like librte_pmd_mlx4 or librte_pmd_oce? Is it available for
reference?

2) What are the pre-requisites to start using PMD for a thirdparty NIC vendor ?

3) Things to keep in mind if any for using dpdk ?

4) My understanding is that dpdk can also work other than IA arch but
with some penalty (eg: ppc)? Is that right ?

Thx
harish

[dpdk-dev] Random mbuf corruption

[Stefan Baranoff]

Paul,

Thanks for the advice; we ran memtest as well as the Dell complete system
diagnostic and neither found an issue. The plot thickens, though!

Our admins messed up our kickstart labels and what I *thought* was CentOS
6.4 was actually RHEL 6.4 and the problem seems to be following the CentOS
6.4 installations -- the current configuration of success/failure is:
  1 server - Westmere - RHEL 6.4 -- works
  1 server - Sandy Bridge - RHEL 6.4 -- works
  2 servers - Sandy Bridge - CentOS 6.4 -- fails

Given that the hardware seems otherwise stable/checks out I'm trying to
figure out how to determine if this is:
  a) our software has a bug
  b) a kernel/hugetlbfs bug
  c) a  DPDK 1.6.0r2 bug

I have seen similar issues where calling rte_eal_init too late in a process
also causes similar issues (things like calling 'free' on memory that was
allocated with 'malloc' before 'rte_eal_init' is called fails/results in
segfault in libc) which seems odd to me but in this case we are calling
rte_eal_init as the first thing we do in main().


Thanks,
Stefan


On Fri, Jun 20, 2014 at 9:59 AM, Paul Barrette 
wrote:

>
> On 06/20/2014 07:20 AM, Stefan Baranoff wrote:
>
>> All,
>>
>> We are seeing 'random' memory corruption in mbufs coming from the ixgbe
>> UIO
>> driver and I am looking for some pointers on debugging it. Our software
>> was
>> running flawlessly for weeks at a time on our old Westmere systems (CentOS
>> 6.4) but since moving to a new Sandy Bridge v2 server (also CentOS 6.4) it
>> runs for 1-2 minutes and then at least one mbuf is overwritten with
>> arbitrary data (pointers/lengths/RSS value/num segs/etc. are all
>> ridiculous). Both servers are using the 82599EB chipset (x520) and the
>> DPDK
>> version (1.6.0r2) is identical. We recently also tested on a third server
>> running RHEL 6.4 with the same hardware as the failing Sandy Bridge based
>> system and it is fine (days of runtime no failures).
>>
>> Running all of this in GDB with 'record' enabled and setting a watchpoint
>> on the address which contains the corrupted data and executing a
>> 'reverse-continue' never hits the watchpoint [GDB newbie here -- assuming
>> 'watch *(uint64_t*)0x7FB.' should work]. My first thought was memory
>> corruption but the BIOS memcheck on the ECC RAM shows no issues.
>>
>> Also looking at mbuf->pkt.data, as an example, the corrupt value was the
>> same 6/12 trials but I could not find that value elsewhere in the
>> processes
>> memory. This doesn't seem "random" and points to a software bug but I
>> cannot for the life of me get GDB to tell me where the program is when
>> that
>> memory is written to. Incidentally trying this with the PCAP driver and
>> --no-huge to run valgrind shows no memory access errors/uninitialized
>> values/etc.
>>
>> Thoughts? Pointers? Ways to rule in/out hardware other than going 1 by 1
>> removing each of the 24 DIMMs?
>>
>> Thanks so much in advance!
>> Stefan
>>
> Run memtest to rule out bad ram.
>
> Pb
>

[dpdk-dev] Why rte_snprintf at all?

[Richardson, Bruce]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Monday, June 23, 2014 10:16 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Why rte_snprintf at all?
> 
> Why does rte_snprintf exist? It seems like a misunderstanding or broken
> implementation of snprintf in some other C library. For standard Glibc,
> I get same result from rte_snprintf and snprintf for all inputs including
> boundary cases

It can indeed probably be deprecated in next release. Any objections?

/Bruce

[dpdk-dev] Why rte_snprintf at all?

[Rogers, Gerald]

Bruce, Stephen,

It may be a duplicate, but people are likely using it.  I would assume
deprecate means don?t remove, but put in a comment that says please don?t
use and migrate your code away from it.

Thanks,

Gerald

On 6/23/14, 3:18 PM, "Richardson, Bruce" 
wrote:

>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
>> Sent: Monday, June 23, 2014 10:16 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] Why rte_snprintf at all?
>> 
>> Why does rte_snprintf exist? It seems like a misunderstanding or broken
>> implementation of snprintf in some other C library. For standard Glibc,
>> I get same result from rte_snprintf and snprintf for all inputs
>>including
>> boundary cases
>
>It can indeed probably be deprecated in next release. Any objections?
>
>/Bruce

[dpdk-dev] Why rte_snprintf at all?

[Wiles, Roger Keith]

Why not just convert it into a macro and ifdef out the code or remove it. This 
way it can we remove later or just kept for some backward compat reason.

#define rte_snprintf snprintf

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jun 23, 2014, at 5:25 PM, Rogers, Gerald mailto:gerald.rogers at intel.com>> wrote:

Bruce, Stephen,

It may be a duplicate, but people are likely using it.  I would assume
deprecate means don?t remove, but put in a comment that says please don?t
use and migrate your code away from it.

Thanks,

Gerald

On 6/23/14, 3:18 PM, "Richardson, Bruce" mailto:bruce.richardson at intel.com>>
wrote:

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
Sent: Monday, June 23, 2014 10:16 AM
To: dev at dpdk.org
Subject: [dpdk-dev] Why rte_snprintf at all?

Why does rte_snprintf exist? It seems like a misunderstanding or broken
implementation of snprintf in some other C library. For standard Glibc,
I get same result from rte_snprintf and snprintf for all inputs
including
boundary cases

It can indeed probably be deprecated in next release. Any objections?

/Bruce

[dpdk-dev] Why rte_snprintf at all?

[Richardson, Bruce]

That could work, Keith.
However, I would suggest we make use of the gcc "deprecated" function attribute 
in 1.8 to flag it for future removal in a subsequent release. [Ref: 
https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html]. That's what the 
attribute is there for.

From: Wiles, Roger Keith [mailto:keith.wi...@windriver.com]
Sent: Monday, June 23, 2014 3:31 PM
To: Rogers, Gerald
Cc: Richardson, Bruce; Stephen Hemminger; dev at dpdk.org
Subject: Re: [dpdk-dev] Why rte_snprintf at all?

Why not just convert it into a macro and ifdef out the code or remove it. This 
way it can we remove later or just kept for some backward compat reason.

#define rte_snprintf  snprintf

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jun 23, 2014, at 5:25 PM, Rogers, Gerald mailto:gerald.rogers at intel.com>> wrote:


Bruce, Stephen,

It may be a duplicate, but people are likely using it.  I would assume
deprecate means don?t remove, but put in a comment that says please don?t
use and migrate your code away from it.

Thanks,

Gerald

On 6/23/14, 3:18 PM, "Richardson, Bruce" mailto:bruce.richardson at intel.com>>
wrote:


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
Sent: Monday, June 23, 2014 10:16 AM
To: dev at dpdk.org
Subject: [dpdk-dev] Why rte_snprintf at all?

Why does rte_snprintf exist? It seems like a misunderstanding or broken
implementation of snprintf in some other C library. For standard Glibc,
I get same result from rte_snprintf and snprintf for all inputs
including
boundary cases

It can indeed probably be deprecated in next release. Any objections?

/Bruce

[dpdk-dev] Why rte_snprintf at all?

[Wiles, Roger Keith]

Bruce,

Will the deprecated attribute stop the build as warns are converted to errors? 
Having warns as errors is a good idea IMO, as some warns will cause a problem 
in execution sometimes or portability.

One suggestion is we can ifdef out the code, but also place the deprecated 
attribute on the function. Then the #else side of the ifdef is the #define to 
use snprintf. This way if they enable the ifdef they must live with the problem 
of deprecation later. Does 1.7 not support the deprecated attribute, maybe that 
was your point. :-)

I see a lot of code using rte_snprintf and I hate to change all of the code, 
but it is a simple find/replace sed script.
It is up to you guys I was just suggesting a simple fix for this release 
instead of the next release.

Thanks
Keith

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jun 23, 2014, at 5:34 PM, Richardson, Bruce mailto:bruce.richardson at intel.com>> wrote:

That could work, Keith.
However, I would suggest we make use of the gcc ?deprecated? function attribute 
in 1.8 to flag it for future removal in a subsequent release. [Ref: 
https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html]. That?s what the 
attribute is there for.

From: Wiles, Roger Keith [mailto:keith.wi...@windriver.com]
Sent: Monday, June 23, 2014 3:31 PM
To: Rogers, Gerald
Cc: Richardson, Bruce; Stephen Hemminger; dev at dpdk.org
Subject: Re: [dpdk-dev] Why rte_snprintf at all?

Why not just convert it into a macro and ifdef out the code or remove it. This 
way it can we remove later or just kept for some backward compat reason.

#define rte_snprintf  snprintf

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jun 23, 2014, at 5:25 PM, Rogers, Gerald mailto:gerald.rogers at intel.com>> wrote:


Bruce, Stephen,

It may be a duplicate, but people are likely using it.  I would assume
deprecate means don?t remove, but put in a comment that says please don?t
use and migrate your code away from it.

Thanks,

Gerald

On 6/23/14, 3:18 PM, "Richardson, Bruce" mailto:bruce.richardson at intel.com>>
wrote:


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
Sent: Monday, June 23, 2014 10:16 AM
To: dev at dpdk.org
Subject: [dpdk-dev] Why rte_snprintf at all?

Why does rte_snprintf exist? It seems like a misunderstanding or broken
implementation of snprintf in some other C library. For standard Glibc,
I get same result from rte_snprintf and snprintf for all inputs
including
boundary cases

It can indeed probably be deprecated in next release. Any objections?

/Bruce

[dpdk-dev] Why rte_snprintf at all?

[Richardson, Bruce]

Hi Keith,

Will the deprecation warnings stop the build? I would assume so, yes. That 
would serve as incentive for doing a search-replace to remove the deprecated 
function. J

As for the #define, it's a quick fix, except that we end up having to keep it 
forever as the code using the function will never get changed to use 
rte_snprintf. Given it's just a one-line macro, it's probably not a big deal in 
this case, but I'd rather see us take the approach that after something has 
been flagged as deprecated for a certain amount of time e.g. 1 to 2 full 
release cycles, it is removed completely and deleted. Otherwise I worry about 
us having to maintain a bunch of stuff for legacy reasons, that really should 
be got rid of. We should not just remove something completely in a single 
release, but I think we need to have a way to remove things completely once the 
user has been given sufficient warning.

Regards,

/Bruce

From: Wiles, Roger Keith [mailto:keith.wi...@windriver.com]
Sent: Monday, June 23, 2014 3:46 PM
To: Richardson, Bruce
Cc: Rogers, Gerald; Stephen Hemminger; dev at dpdk.org
Subject: Re: [dpdk-dev] Why rte_snprintf at all?

Bruce,

Will the deprecated attribute stop the build as warns are converted to errors? 
Having warns as errors is a good idea IMO, as some warns will cause a problem 
in execution sometimes or portability.

One suggestion is we can ifdef out the code, but also place the deprecated 
attribute on the function. Then the #else side of the ifdef is the #define to 
use snprintf. This way if they enable the ifdef they must live with the problem 
of deprecation later. Does 1.7 not support the deprecated attribute, maybe that 
was your point. :-)

I see a lot of code using rte_snprintf and I hate to change all of the code, 
but it is a simple find/replace sed script.
It is up to you guys I was just suggesting a simple fix for this release 
instead of the next release.

Thanks
Keith

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jun 23, 2014, at 5:34 PM, Richardson, Bruce mailto:bruce.richardson at intel.com>> wrote:


That could work, Keith.
However, I would suggest we make use of the gcc "deprecated" function attribute 
in 1.8 to flag it for future removal in a subsequent release. [Ref: 
https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html]. That's what the 
attribute is there for.

From: Wiles, Roger Keith [mailto:keith.wi...@windriver.com]
Sent: Monday, June 23, 2014 3:31 PM
To: Rogers, Gerald
Cc: Richardson, Bruce; Stephen Hemminger; dev at dpdk.org
Subject: Re: [dpdk-dev] Why rte_snprintf at all?

Why not just convert it into a macro and ifdef out the code or remove it. This 
way it can we remove later or just kept for some backward compat reason.

#define rte_snprintf  snprintf

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jun 23, 2014, at 5:25 PM, Rogers, Gerald mailto:gerald.rogers at intel.com>> wrote:



Bruce, Stephen,

It may be a duplicate, but people are likely using it.  I would assume
deprecate means don?t remove, but put in a comment that says please don?t
use and migrate your code away from it.

Thanks,

Gerald

On 6/23/14, 3:18 PM, "Richardson, Bruce" mailto:bruce.richardson at intel.com>>
wrote:



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
Sent: Monday, June 23, 2014 10:16 AM
To: dev at dpdk.org
Subject: [dpdk-dev] Why rte_snprintf at all?

Why does rte_snprintf exist? It seems like a misunderstanding or broken
implementation of snprintf in some other C library. For standard Glibc,
I get same result from rte_snprintf and snprintf for all inputs
including
boundary cases

It can indeed probably be deprecated in next release. Any objections?

/Bruce

[dpdk-dev] NIC-related dpdk questions.

[Harish Patil]

Folks,
Pls let me know if this is not the right forum or provide pointers for
the questions that I asked.

Harish

On Mon, Jun 23, 2014 at 2:22 PM, Harish Patil  wrote:
> Folks,
> I?m a newbie going thru? dpdk. Have few quick questions.
>
> 1) Where can I find implementations of PMD of third party (non-Intel)
> adapters like librte_pmd_mlx4 or librte_pmd_oce? Is it available for
> reference?
>
> 2) What are the pre-requisites to start using PMD for a thirdparty NIC vendor 
> ?
>
> 3) Things to keep in mind if any for using dpdk ?
>
> 4) My understanding is that dpdk can also work other than IA arch but
> with some penalty (eg: ppc)? Is that right ?
>
> Thx
> harish