[dpdk-dev] [PATCH v3] doc: add known issue about promiscuous mode for I40e VF

[Jeff Guo]

When use i40e linux kernel driver as host driver and DPDK handler the i40e
VF, the promiscuous mode doesn't work in i40e VF. It is not supported by
DPDK i40e VF driver right now.

Signed-off-by: Jeff Guo 
---
v2->v3:
- Title underline align and refine some description

 doc/guides/rel_notes/known_issues.rst | 20 
 1 file changed, 20 insertions(+)

diff --git a/doc/guides/rel_notes/known_issues.rst 
b/doc/guides/rel_notes/known_issues.rst
index 5ec1987..3cd4237 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -620,3 +620,23 @@ The last EAL argument is replaced by the program name in 
argv[]

 **Driver/Module**:
Environment Abstraction Layer (EAL).
+
+
+I40e VF may not receive packets in the promiscuous mode
+---
+
+**Description**:
+   Promiscuous mode is not supported by the DPDK i40e VF driver when using the
+   i40e Linux kernel driver as host driver.
+
+**Implication**:
+   The i40e VF does not receive packets when the destination MAC address is 
unknown.
+
+**Resolution/Workaround**:
+   Use a explicit destination MAC address that matches the VF.
+
+**Affected Environment/Platform**:
+   All.
+
+**Driver/Module**:
+   Poll Mode Driver (PMD).
-- 
1.9.3

[dpdk-dev] [PATCH v3] i40: fix the VXLAN TSO issue

[Tan, Jianfeng]

Hi Konstantin,


On 7/19/2016 6:29 PM, Ananyev, Konstantin wrote:
>
>> Problem:
>> When using the TSO + VXLAN feature in i40e, the outer UDP length fields in 
>> the multiple UDP segments which are TSOed by the i40e will
>> have a wrong value.
>>
>> Fix this problem by adding the tunnel type field in the i40e descriptor 
>> which was missed before.
>>
>> Fixes: 77b8301733c3 ("i40e: VXLAN Tx checksum offload")
>>
>> Signed-off-by: Zhe Tao 
>> ---
>> v2: edited the comments
>> v3: added external IP offload flag when TSO is enabled for tunnelling packets
>>
>>   app/test-pmd/csumonly.c  | 29 +
>>   drivers/net/i40e/i40e_rxtx.c | 12 +---
>>   lib/librte_mbuf/rte_mbuf.h   | 16 +++-
>>   3 files changed, 45 insertions(+), 12 deletions(-)
>>
>> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c index 
>> ac4bd8f..aaa006f 100644
>> --- a/app/test-pmd/csumonly.c
>> +++ b/app/test-pmd/csumonly.c
>> @@ -204,7 +204,8 @@ parse_ethernet(struct ether_hdr *eth_hdr, struct 
>> testpmd_offload_info *info)  static void  parse_vxlan(struct
>> udp_hdr *udp_hdr,
>>  struct testpmd_offload_info *info,
>> -uint32_t pkt_type)
>> +uint32_t pkt_type,
>> +uint64_t *ol_flags)
>>   {
>>  struct ether_hdr *eth_hdr;
>>
>> @@ -215,6 +216,7 @@ parse_vxlan(struct udp_hdr *udp_hdr,
>>  RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
>>  return;
>>
>> +*ol_flags |= PKT_TX_TUNNEL_VXLAN;
>
> Hmm, I don't actually see much difference between that version and the 
> previous one.
>   Regarding your comment on V2:
> " this flag is for tunnelling type, and CTD is based on whether we need to do 
> the
> external ip offload and TSO.so this flag will not cause one extra CTD."
> I think CTD selection should be based not only on is EIP cksum is enabled or 
> not.
> You can have tunneled packet with TSO on over IPv6, right?
> I think for i40e we need CTD each time PKT_TX_TUNNEL_ is on.

Yes, I agree. Depending on whether EIP cksum is enabled to fill 
tunneling parameters is not correct under the case: EIP cksum is not 
needed, tso is needed (tunneling parameter will not be filled). And app 
should not set PKT_TX_TUNNEL_ if there's no TSO and no checksum offload 
to avoid extra filling of tunneling parameters.

Another corner case is that, EIP cksum not needed, TSO not needed, but 
inner L3/L4 checksum needed, so:
(1) App to set PKT_TX_TUNNEL_ on, but in this case, no extra CTD will be 
used according to i40e_calc_context_desc(), so it cannot work right.
(2) App to unset PKT_TX_TUNNEL_, will not work either.

How do you think?
(Sorry, the answer is in your following comments. We need to change 
i40e_calc_context_desc() to return 1 if PKT_TX_TUNNEL_ is on.)


>
>
>>  info->is_tunnel = 1;
>>  info->outer_ethertype = info->ethertype;
>>  info->outer_l2_len = info->l2_len;
>> @@ -231,7 +233,9 @@ parse_vxlan(struct udp_hdr *udp_hdr,
>>
>>   /* Parse a gre header */
>>   static void
>> -parse_gre(struct simple_gre_hdr *gre_hdr, struct testpmd_offload_info *info)
>> +parse_gre(struct simple_gre_hdr *gre_hdr,
>> +  struct testpmd_offload_info *info,
>> +  uint64_t *ol_flags)
>>   {
>>  struct ether_hdr *eth_hdr;
>>  struct ipv4_hdr *ipv4_hdr;
>> @@ -242,6 +246,8 @@ parse_gre(struct simple_gre_hdr *gre_hdr, struct 
>> testpmd_offload_info *info)
>>  if ((gre_hdr->flags & _htons(~GRE_SUPPORTED_FIELDS)) != 0)
>>  return;
>>
>> +*ol_flags |= PKT_TX_TUNNEL_GRE;
>> +
>>  gre_len += sizeof(struct simple_gre_hdr);
>>
>>  if (gre_hdr->flags & _htons(GRE_KEY_PRESENT)) @@ -417,7 +423,7 @@ 
>> process_inner_cksums(void *l3_hdr, const struct
>> testpmd_offload_info *info,
>>* packet */
>>   static uint64_t
>>   process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info *info,
>> -uint16_t testpmd_ol_flags)
>> +uint16_t testpmd_ol_flags, uint64_t orig_ol_flags)
>>   {
>>  struct ipv4_hdr *ipv4_hdr = outer_l3_hdr;
>>  struct ipv6_hdr *ipv6_hdr = outer_l3_hdr; @@ -428,7 +434,8 @@ 
>> process_outer_cksums(void *outer_l3_hdr, struct
>> testpmd_offload_info *info,
>>  ipv4_hdr->hdr_checksum = 0;
>>  ol_flags |= PKT_TX_OUTER_IPV4;
>>
>> -if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM)
>> +if ((testpmd_ol_flags & TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM) ||
>> +(info->tso_segsz != 0))
>>  ol_flags |= PKT_TX_OUTER_IP_CKSUM;
> Why do you need to always raise OUTER_IP_CKSUM when TSO is enabled?

I believe it's not necessary if we fill tunneling parameters according 
to PKT_TX_TUNNEL_ as you suggest above.

>
>>  else
>>  ipv4_hdr->hdr_checksum = rte_ipv4_cksum(ipv4_hdr); @@ 
>> -442,6 +449,9 @@ process_outer_cksums(void
>> *outer_l3_hdr, struct testpmd_offload_info *info,
>>   * hardware supporting it today, and no API for it. */
>>
>>  udp_hdr = (struct 

[dpdk-dev] [PATCH v2] ethdev: fix documentation for queue start/stop

[Nikhil Rao]

Fix documentation for rte_eth_dev_tx/rx_queue_start/stop() functions

Fixes: 2de9f8551ff9 ("ethdev: fix documentation for queue start/stop")

Signed-off-by: Nikhil Rao 
---

v2:

* Updated as per review comments from John McNamara.
* Previous patch did not apply on master.
* Used started/stopped for Rx queue instead of enabled/disabled
  thanks to Ferruh Yigit.

 lib/librte_ether/rte_ethdev.h | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 4dac364..b0fe033 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2042,9 +2042,8 @@ int rte_eth_dev_socket_id(uint8_t port_id);
 int rte_eth_dev_is_valid_port(uint8_t port_id);

 /**
- * Allocate mbuf from mempool, setup the DMA physical address
- * and then start RX for specified queue of a port. It is used
- * when rx_deferred_start flag of the specified queue is true.
+ * Start specified RX queue of a port. It is used when rx_deferred_start
+ * flag of the specified queue is true.
  *
  * @param port_id
  *   The port identifier of the Ethernet device
@@ -2053,7 +2052,7 @@ int rte_eth_dev_is_valid_port(uint8_t port_id);
  *   The value must be in the range [0, nb_rx_queue - 1] previously supplied
  *   to rte_eth_dev_configure().
  * @return
- *   - 0: Success, the transmit queue is correctly set up.
+ *   - 0: Success, the receive queue is started.
  *   - -EINVAL: The port_id or the queue_id out of range.
  *   - -ENOTSUP: The function not supported in PMD driver.
  */
@@ -2069,7 +2068,7 @@ int rte_eth_dev_rx_queue_start(uint8_t port_id, uint16_t 
rx_queue_id);
  *   The value must be in the range [0, nb_rx_queue - 1] previously supplied
  *   to rte_eth_dev_configure().
  * @return
- *   - 0: Success, the transmit queue is correctly set up.
+ *   - 0: Success, the receive queue is stopped.
  *   - -EINVAL: The port_id or the queue_id out of range.
  *   - -ENOTSUP: The function not supported in PMD driver.
  */
@@ -2086,7 +2085,7 @@ int rte_eth_dev_rx_queue_stop(uint8_t port_id, uint16_t 
rx_queue_id);
  *   The value must be in the range [0, nb_tx_queue - 1] previously supplied
  *   to rte_eth_dev_configure().
  * @return
- *   - 0: Success, the transmit queue is correctly set up.
+ *   - 0: Success, the transmit queue is started.
  *   - -EINVAL: The port_id or the queue_id out of range.
  *   - -ENOTSUP: The function not supported in PMD driver.
  */
@@ -2102,7 +2101,7 @@ int rte_eth_dev_tx_queue_start(uint8_t port_id, uint16_t 
tx_queue_id);
  *   The value must be in the range [0, nb_tx_queue - 1] previously supplied
  *   to rte_eth_dev_configure().
  * @return
- *   - 0: Success, the transmit queue is correctly set up.
+ *   - 0: Success, the transmit queue is stopped.
  *   - -EINVAL: The port_id or the queue_id out of range.
  *   - -ENOTSUP: The function not supported in PMD driver.
  */
-- 
2.7.4

[dpdk-dev] [PATCH] doc : update guide and release notes for mlx5

[Olga Shern]

Signed-off-by: Olga Shern 
---
 doc/guides/nics/mlx5.rst   |7 ++-
 doc/guides/rel_notes/release_16_07.rst |   16 +++-
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 063c4a5..1bcb818 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -154,6 +154,11 @@ Run-time configuration
   allows to save PCI bandwidth and improve performance at the cost of a
   slightly higher CPU usage.  Enabled by default.

+  Supported on:
+
+  - x86_64 with ConnectX4 and ConnectX4 LX
+  - Power8 with ConnectX4 LX
+
 - ``txq_inline`` parameter [int]

   Amount of data to be inlined during TX operations. Improves latency.
@@ -234,7 +239,7 @@ DPDK and must be installed separately:

 Currently supported by DPDK:

-- Mellanox OFED **3.3-1.0.0.0**.
+- Mellanox OFED **3.3-1.0.0.0** and **3.3-2.0.0.0**

 - Minimum firmware version:

diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index d00a6ed..b48f676 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -191,7 +191,21 @@ New Features

   Live migration of a VM with Virtio and VF PMD's using the bonding PMD.

-
+* **Updated the mlx5 driver.**
+
+  The mlx5 driver was updated with changes including the following:
+
+  * Data path was refactored to bypass Verbs to improve RX and TX performance.
+  * Removed compilation parameters for inline send, MLX5_MAX_INLINE, and
+added command line parameter instead, txq_inline.
+  * Improved TX scatter gather support: 
+Removed compilation parameter MLX5_PMD_SGE_WR_N.
+Scatter-gather elements is set to the maximum value the NIC supports.
+Removed linearization logic, this decreases the memory consumption of the 
PMD.
+  * Improved jumbo frames support, by dynamically setting RX scatter gather 
elements
+according to the MTU and mbuf size,
+no need for compilation parameter MLX5_PMD_SGE_WR_N.
+ 
 Resolved Issues
 ---

-- 
1.7.8.2

[dpdk-dev] [PATCH] doc: fix incorrect path to testpmd app

[Shreyansh Jain]

Signed-off-by: Shreyansh Jain 
---
 doc/guides/testpmd_app_ug/build_app.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/testpmd_app_ug/build_app.rst 
b/doc/guides/testpmd_app_ug/build_app.rst
index 7f32a7c..4c7cf2e 100644
--- a/doc/guides/testpmd_app_ug/build_app.rst
+++ b/doc/guides/testpmd_app_ug/build_app.rst
@@ -58,4 +58,4 @@ The basic compilation steps are:

 .. code-block:: console

-$RTE_SDK/$RTE_TARGET/build/app/testpmd
+$RTE_SDK/$RTE_TARGET/app/testpmd
-- 
2.7.4

[dpdk-dev] [PATCH] doc: announce renaming of ethdev library

[Thomas Monjalon]

The right name of ethdev should be dpdk_netdev. However:
1/ We are using rte_ prefix in the code and library names.
2/ The API uses rte_ethdev
That's why 16.11 will just have the rte_ prefix prepended to
the library filename as every other libraries.

Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index f502f86..7a55037 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,6 +11,9 @@ Deprecation Notices
 * The log history is deprecated.
   It is voided in 16.07 and will be removed in release 16.11.

+* The ethdev library file will be renamed from libethdev.* to librte_ethdev.*
+  in release 16.11 in order to have a more consistent namespace.
+
 * The ethdev hotplug API is going to be moved to EAL with a notification
   mechanism added to crypto and ethdev libraries so that hotplug is now
   available to both of them. This API will be stripped of the device arguments
-- 
2.7.0

[dpdk-dev] [PATCH] ethdev: fix documentation for queue start/stop functions

[Nikhil P Rao]

From: nikhil@intel.com

Fix documentation for rte_eth_dev_tx/rx_queue_start/stop() functions

Signed-off-by: Nikhil Rao 
---
 lib/librte_ether/rte_ethdev.h | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 022733e..d72fab9 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2039,9 +2039,7 @@ int rte_eth_dev_socket_id(uint8_t port_id);
 int rte_eth_dev_is_valid_port(uint8_t port_id);

 /*
- * Allocate mbuf from mempool, setup the DMA physical address
- * and then start RX for specified queue of a port. It is used
- * when rx_deferred_start flag of the specified queue is true.
+ * Start specified RX queue of a port.
  *
  * @param port_id
  *   The port identifier of the Ethernet device
@@ -2050,7 +2048,7 @@ int rte_eth_dev_is_valid_port(uint8_t port_id);
  *   The value must be in the range [0, nb_rx_queue - 1] previously supplied
  *   to rte_eth_dev_configure().
  * @return
- *   - 0: Success, the transmit queue is correctly set up.
+ *   - 0: Success, the receive queue is enabled.
  *   - -EINVAL: The port_id or the queue_id out of range.
  *   - -ENOTSUP: The function not supported in PMD driver.
  */
@@ -2066,7 +2064,7 @@ int rte_eth_dev_rx_queue_start(uint8_t port_id, uint16_t 
rx_queue_id);
  *   The value must be in the range [0, nb_rx_queue - 1] previously supplied
  *   to rte_eth_dev_configure().
  * @return
- *   - 0: Success, the transmit queue is correctly set up.
+ *   - 0: Success, the receive queue is disabled.
  *   - -EINVAL: The port_id or the queue_id out of range.
  *   - -ENOTSUP: The function not supported in PMD driver.
  */
@@ -2083,7 +2081,7 @@ int rte_eth_dev_rx_queue_stop(uint8_t port_id, uint16_t 
rx_queue_id);
  *   The value must be in the range [0, nb_tx_queue - 1] previously supplied
  *   to rte_eth_dev_configure().
  * @return
- *   - 0: Success, the transmit queue is correctly set up.
+ *   - 0: Success, the transmit queue is started
  *   - -EINVAL: The port_id or the queue_id out of range.
  *   - -ENOTSUP: The function not supported in PMD driver.
  */
@@ -2099,7 +2097,7 @@ int rte_eth_dev_tx_queue_start(uint8_t port_id, uint16_t 
tx_queue_id);
  *   The value must be in the range [0, nb_tx_queue - 1] previously supplied
  *   to rte_eth_dev_configure().
  * @return
- *   - 0: Success, the transmit queue is correctly set up.
+ *   - 0: Success, the transmit queue is stopped
  *   - -EINVAL: The port_id or the queue_id out of range.
  *   - -ENOTSUP: The function not supported in PMD driver.
  */
-- 
2.7.4

[dpdk-dev] [PATCH 2/2] doc: l2fwd: document new --[no-]mac-tweaking option

[Maxime Coquelin]

This patch documents the new l2fwd option, which provides a way to
disable the MAC addresses tweaking, enabling the use of l2fwd for basic
VM to VM communication.

Signed-off-by: Maxime Coquelin 
---
 doc/guides/sample_app_ug/img/l2_fwd_vm2vm.svg  | 311 +
 .../sample_app_ug/l2_forward_real_virtual.rst  |  24 +-
 2 files changed, 329 insertions(+), 6 deletions(-)
 create mode 100644 doc/guides/sample_app_ug/img/l2_fwd_vm2vm.svg

diff --git a/doc/guides/sample_app_ug/img/l2_fwd_vm2vm.svg 
b/doc/guides/sample_app_ug/img/l2_fwd_vm2vm.svg
new file mode 100644
index 000..b84dcb2
--- /dev/null
+++ b/doc/guides/sample_app_ug/img/l2_fwd_vm2vm.svg
@@ -0,0 +1,311 @@
+
+
+
+http://www.openswatchbook.org/uri/2009/osb;
+   xmlns:dc="http://purl.org/dc/elements/1.1/;
+   xmlns:cc="http://creativecommons.org/ns#;
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
+   xmlns:svg="http://www.w3.org/2000/svg;
+   xmlns="http://www.w3.org/2000/svg;
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape;
+   width="554.46204"
+   height="443.63278"
+   viewBox="0 0 554.46204 443.63279"
+   id="svg3917"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="l2_fwd_vm2vm.svg">
+  
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+  
+  
+  
+
+  
+image/svg+xml
+http://purl.org/dc/dcmitype/StillImage; />
+
+  
+
+  
+  
+
+Host
+
+
+Guest1
+Guest2
+
+L2FWD
+
+
+
+
+
+
+  
+
diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst 
b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
index a1c10c0..dcb486c 100644
--- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
+++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
@@ -50,15 +50,17 @@ performs L2 forwarding for each packet that is received on 
an RX_PORT.
 The destination port is the adjacent port from the enabled portmask, that is,
 if the first four ports are enabled (portmask 0xf),
 ports 1 and 2 forward into each other, and ports 3 and 4 forward into each 
other.
-Also, the MAC addresses are affected as follows:
+Also, if MAC addresses tweaking is enabled, the MAC addresses are affected as 
follows:

 *   The source MAC address is replaced by the TX_PORT MAC address

 *   The destination MAC address is replaced by  02:00:00:00:00:TX_PORT_ID

-This application can be used to benchmark performance using a 
traffic-generator, as shown in the :numref:`figure_l2_fwd_benchmark_setup`.
+This application can be used to benchmark performance using a 
traffic-generator, as shown in the :numref:`figure_l2_fwd_benchmark_setup`,
+or in a virtualized environment as shown in 
:numref:`figure_l2_fwd_virtenv_benchmark_setup`.

-The application can also be used in a virtualized environment as shown in 
:numref:`figure_l2_fwd_virtenv_benchmark_setup`.
+This application can also be used for basic VM to VM communication as shown in 
:numref:`figure_l2_fwd_vm2vm`,
+when MAC addresses tweaking is disabled.

 The L2 Forwarding application can also be used as a starting point for 
developing a new application based on the DPDK.

@@ -75,6 +77,12 @@ The L2 Forwarding application can also be used as a starting 
point for developin

Performance Benchmark Setup (Virtualized Environment)

+.. _figure_l2_fwd_vm2vm:
+
+.. figure:: img/l2_fwd_vm2vm.*
+
+   Virtual Machine to Virtual Machine communication.
+
 .. _l2_fwd_vf_setup:

 Virtual Function Setup Instructions
@@ -128,7 +136,7 @@ The application requires a number of command line options:

 .. code-block:: console

-./build/l2fwd [EAL options] -- -p PORTMASK [-q NQ]
+./build/l2fwd [EAL options] -- -p PORTMASK [-q NQ] --[no-]mac-tweaking

 where,

@@ -136,7 +144,10 @@ where,

 *   q NQ: A number of queues (=ports) per lcore (default is 1)

-To run the application in linuxapp environment with 4 lcores, 16 ports and 8 
RX queues per lcore, issue the command:
+*   --[no-]mac-tweaking: Enable or disable MAC addresses tweaking (enabled by 
default).
+
+To run the application in linuxapp environment with 4 lcores, 16 ports and 8 
RX queues per lcore and MAC address
+tweaking enabled, issue the command:

 .. code-block:: console

@@ -415,7 +426,8 @@ Packets are read in a burst of size MAX_PKT_BURST.
 The rte_eth_rx_burst() function writes the mbuf pointers in a local table and 
returns the number of available mbufs in the table.

 Then, each mbuf in the table is processed by the l2fwd_simple_forward() 
function.
-The processing is very simple: process the TX port from the RX port, then 
replace the source and destination MAC addresses.
+The processing is very simple: process the TX port from the RX port, then 
replace the source and destination MAC addresses 

[dpdk-dev] [PATCH 1/2] examples/l2fwd: Add new option to enable/disable MAC addresses tweaking

[Maxime Coquelin]

l2fwd could be useful for testing virtual devices without the need
of physical ones.

To achieve this, this patch adds a new option to enable/disable the
MAC addresses tweaking done at forwarding time: --[no-]mac-tweaking

By default, MAC address tweaking remains enabled, to keep consistency
with previous usage.

Signed-off-by: Maxime Coquelin 
---
 examples/l2fwd/main.c | 39 +--
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 8897921..2693be1 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -74,6 +74,9 @@

 static volatile bool force_quit;

+/* MAC tweaking enabled by default */
+static int mac_tweaking = 1;
+
 #define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1

 #define NB_MBUF   8192
@@ -186,23 +189,32 @@ print_stats(void)
 }

 static void
-l2fwd_simple_forward(struct rte_mbuf *m, unsigned portid)
+l2fwd_mac_tweaking(struct rte_mbuf *m, unsigned dest_portid)
 {
struct ether_hdr *eth;
void *tmp;
-   unsigned dst_port;
-   int sent;
-   struct rte_eth_dev_tx_buffer *buffer;

-   dst_port = l2fwd_dst_ports[portid];
eth = rte_pktmbuf_mtod(m, struct ether_hdr *);

/* 02:00:00:00:00:xx */
tmp = >d_addr.addr_bytes[0];
-   *((uint64_t *)tmp) = 0x0002 + ((uint64_t)dst_port << 40);
+   *((uint64_t *)tmp) = 0x0002 + ((uint64_t)dest_portid << 40);

/* src addr */
-   ether_addr_copy(_ports_eth_addr[dst_port], >s_addr);
+   ether_addr_copy(_ports_eth_addr[dest_portid], >s_addr);
+}
+
+static void
+l2fwd_simple_forward(struct rte_mbuf *m, unsigned portid)
+{
+   unsigned dst_port;
+   int sent;
+   struct rte_eth_dev_tx_buffer *buffer;
+
+   dst_port = l2fwd_dst_ports[portid];
+
+   if (mac_tweaking)
+   l2fwd_mac_tweaking(m, dst_port);

buffer = tx_buffer[dst_port];
sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
@@ -322,7 +334,11 @@ l2fwd_usage(const char *prgname)
printf("%s [EAL options] -- -p PORTMASK [-q NQ]\n"
   "  -p PORTMASK: hexadecimal bitmask of ports to configure\n"
   "  -q NQ: number of queue (=ports) per lcore (default is 1)\n"
-  "  -T PERIOD: statistics will be refreshed each PERIOD 
seconds (0 to disable, 10 default, 86400 maximum)\n",
+  "  -T PERIOD: statistics will be refreshed each PERIOD 
seconds (0 to disable, 10 default, 86400 maximum)\n"
+  "  --[no-]mac-tweaking: Enable or disable MAC addresses 
tweaking (enabled by default)\n"
+  "  When enabled:\n"
+  "   - The source MAC address is replaced by the TX port 
MAC address\n"
+  "   - The destination MAC address is replaced by 
02:00:00:00:00:TX_PORT_ID\n",
   prgname);
 }

@@ -386,6 +402,8 @@ l2fwd_parse_args(int argc, char **argv)
int option_index;
char *prgname = argv[0];
static struct option lgopts[] = {
+   { "mac-tweaking", no_argument, _tweaking, 1},
+   { "no-mac-tweaking", no_argument, _tweaking, 0},
{NULL, 0, 0, 0}
};

@@ -428,8 +446,7 @@ l2fwd_parse_args(int argc, char **argv)

/* long options */
case 0:
-   l2fwd_usage(prgname);
-   return -1;
+   break;

default:
l2fwd_usage(prgname);
@@ -542,6 +559,8 @@ main(int argc, char **argv)
if (ret < 0)
rte_exit(EXIT_FAILURE, "Invalid L2FWD arguments\n");

+   printf("MAC tweaking %s\n", mac_tweaking ? "enabled" : "disabled");
+
/* convert to number of cycles */
timer_period *= rte_get_timer_hz();

-- 
2.7.4

[dpdk-dev] [PATCH 0/2] examples/l2fwd: Add option to enable/disable MAC addresses tweaking

[Maxime Coquelin]

This series adds a new option to enable/disable MAC addresses tweaking in
l2fwd example.

Doing that, we can enable basic VM 2 VM communication easily, without
external projects dependencies, nor real NIC (as with vhost example).

Example of cli with vhost-user:

#l2fwd -c f --socket-mem=1024 \
--vdev 'eth_vhost0,iface=/tmp/vhost-user1,queues=1' \
--vdev 'eth_vhost1,iface=/tmp/vhost-user2,queues=1' \
-- -p3 --no-mac-tweaking

By default, MAC addresses tweaking remains enabled, but maybe we could
consider having it disabled by default to be consistent with l2fwd-cat
for example.

Maxime Coquelin (2):
  examples/l2fwd: Add new option to enable/disable MAC addresses
tweaking
  doc: l2fwd: document new --[no-]mac-tweaking option

 doc/guides/sample_app_ug/img/l2_fwd_vm2vm.svg  | 311 +
 .../sample_app_ug/l2_forward_real_virtual.rst  |  24 +-
 examples/l2fwd/main.c  |  39 ++-
 3 files changed, 358 insertions(+), 16 deletions(-)
 create mode 100644 doc/guides/sample_app_ug/img/l2_fwd_vm2vm.svg

-- 
2.7.4

[dpdk-dev] [PATCH v2 2/2] eal: fix parsing of eal option --lcores

[Wei Dai]

The '-' in lcore set overrides cpu set of following
lcore set in the argument of EAL option --lcores.
for example --locres '0-2,(3-5)@(3,4),6@(5,6),7@(5-7)',
0-2 make lflags=1 which indeed suppress following
cpu set (3,4), (5,6) and (5-7) after @ .

Fixes: 53e54bf81700 ("eal: new option --lcores for cpu assignment")

Signed-off-by: Wei Dai 
---
 lib/librte_eal/common/eal_common_options.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index c5bf98c..217d08b 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -583,7 +583,7 @@ eal_parse_lcores(const char *lcores)
const char *end = NULL;
int offset;
rte_cpuset_t cpuset;
-   int lflags = 0;
+   int lflags;
int ret = -1;

if (lcores == NULL)
@@ -609,6 +609,8 @@ eal_parse_lcores(const char *lcores)
if (*lcores == '\0')
goto err;

+   lflags = 0;
+
/* record lcore_set start point */
lcore_start = lcores;

-- 
2.5.5

[dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse --lcores

[Wei Dai]

local variable i is not referred by other codes in
the function eal_parse_lcores( ), so it can be removed.

Signed-off-by: Wei Dai 
---
 lib/librte_eal/common/eal_common_options.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 481c732..c5bf98c 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -578,7 +578,6 @@ eal_parse_lcores(const char *lcores)
struct rte_config *cfg = rte_eal_get_configuration();
static uint16_t set[RTE_MAX_LCORE];
unsigned idx = 0;
-   int i;
unsigned count = 0;
const char *lcore_start = NULL;
const char *end = NULL;
@@ -593,9 +592,6 @@ eal_parse_lcores(const char *lcores)
/* Remove all blank characters ahead and after */
while (isblank(*lcores))
lcores++;
-   i = strlen(lcores);
-   while ((i > 0) && isblank(lcores[i - 1]))
-   i--;

CPU_ZERO();

-- 
2.5.5

[dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse --lcores

[Adam Bynes]

On Tue, Jul 26, 2016 at 11:51:57AM +, Ananyev, Konstantin wrote:
> 
> 
hi Wei,
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wei Dai
> > Sent: Tuesday, July 26, 2016 10:52 AM
> > To: dev at dpdk.org
> > Cc: Dai, Wei 
> > Subject: [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse 
> > --lcores
> > 
> > local variable i is not referred by other codes in the function 
> > eal_parse_lcores( ), so it can be removed.
> > 
> > Signed-off-by: Wei Dai 
> > ---
> >  lib/librte_eal/common/eal_common_options.c | 4 
> >  1 file changed, 4 deletions(-)
> > 
> > diff --git a/lib/librte_eal/common/eal_common_options.c 
> > b/lib/librte_eal/common/eal_common_options.c
> > index 481c732..c5bf98c 100644
> > --- a/lib/librte_eal/common/eal_common_options.c
> > +++ b/lib/librte_eal/common/eal_common_options.c
> > @@ -578,7 +578,6 @@ eal_parse_lcores(const char *lcores)
> > struct rte_config *cfg = rte_eal_get_configuration();
> > static uint16_t set[RTE_MAX_LCORE];
> > unsigned idx = 0;
> > -   int i;
> > unsigned count = 0;
> > const char *lcore_start = NULL;
> > const char *end = NULL;
> > @@ -593,9 +592,6 @@ eal_parse_lcores(const char *lcores)
> > /* Remove all blank characters ahead and after */
> > while (isblank(*lcores))
> > lcores++;
> > -   i = strlen(lcores);
> > -   while ((i > 0) && isblank(lcores[i - 1]))
> > -   i--;
> 
> I suppose originally it meant to do something  like that:
> while ((i > 0) && isblank(lcores[i - 1]))
>   lcores[i--] = 0;
totally agreed Konstantin, need to add lcore[i--] = '\0'

> 
> to get rid of blank characters at the end of the line, no?
> Konstantin
> 
> > 
> > CPU_ZERO();
> > 
> > --
> > 2.5.5
Adam Bynes

[dpdk-dev] Virtio crash

[Prabahar Radhakrishnan]

Hi,
 I am trying to enable virtio for our application.  The driver
registration is all working and initialization is fine as well.  But, when
I call "*rte_eth_rx_burst()*" API to receive packets, driver crashes  "
*virtio_recv_mergeable_pkts()*" while calling "VIRTQUEUE_NUSED()".  Looks
like the vq_ring is not initialized.  I am using dpdk-2.2 and I saw that in
the archives there was an issue in dpdk-2.2 in device restart.  I don't
have a device restart condition.  Any idea what might be happening?

Device restart issue I am referring to:
http://openvswitch.org/pipermail/discuss/2016-March/020551.html

Thank you
regards Prab

[dpdk-dev] [PATCH v2] net/i40e: remove weak symbols

[Zoltan Kiss]

Hi,

I forgot to add the i40 maintainers as well. Would anyone like to weigh in?

Regards,

Zoltan

On 22/07/16 12:34, Zoltan Kiss wrote:
>
>
> On 21/07/16 19:58, bynes adam wrote:
>> On Wed, Jul 20, 2016 at 06:11:16PM +0100, Zoltan Kiss wrote:
>> Hi, Kiss
>>> Using weak symbols have a few issues with static linking:
>>>
>>> - normally the linker searches the .o files already linked, if your weak
>>>   one is there, it won't check if there is a strong version
>>> - unless the symbol is directly referred, but it's not the right
>>> thing to
>>>   rely on
>>> - or --whole-archive specified in the command line, which pulls in a lot
>>>   of unwanted stuff
>> --whole-archive on the other hand can ensure all the object files are
>> linked,
>> and the strong symbol will take precedence over weak symbol. So we
>> don't need to
>> take care of the sequence of the object files in the ar or between ar.
>
> --whole-archive is primarily for shared libraries, just as weak symbols.
> When people do static linking, their reason is often to avoid carrying
> around a big library while they only use a fraction of it.
>
>>> - whole-archive also makes libtool dropping the library from the command
>>>   line, which is what should happen with dynamic linking, but not with
>>>   static (observed on Ubuntu 14.04). This is an important bug if you
>>>   build a static library depending on DPDK
>> you mean the libtool bug for --whole-archive?
>> if it does, you shouldn't using the libtool,
>
> GNU libtool is a quite common tool for building libraries, it's a bit
> painful sometimes, but it works. What else do you recommend? I mean,
> something which is proven to be better?
>
>> BTW what's the circumstance you must use the libtool. using you own
>> makefile for
>> the library or APP.
>
> Building libraries which depend on DPDK
>
>>>
>>> This patch merges the two version and make the behaviour rely on the
>>> config.
>>>
>>> If we can agree in the concept, I can send a series to fix this for the
>>> other weak functions.
>>>
>>> Signed-off-by: Zoltan Kiss 
>>> ---
>>>
>>> Notes:
>>> v2: fix commit message
>>>
>>>  drivers/net/i40e/i40e_rxtx.c | 36
>>> +++-
>>>  drivers/net/i40e/i40e_rxtx_vec.c | 36
>>> 
>>>  2 files changed, 35 insertions(+), 37 deletions(-)
>>>
>> From the original design, we follow the rule, we don't want the Macro
>> in the file
>> to seperate the different Rx/Tx path for disabled/enabled vector
>> configuration.
>
> And why is it better to compile two versions of the same function when
> you already know at the time of compilation which one do you want to use?
>
>> Adam Bynes
>>

[dpdk-dev] [RFC] Generic flow director/filtering/classification API

[Rahul Lakkireddy]

On Monday, July 07/25/16, 2016 at 09:40:02 -0700, John Fastabend wrote:
> On 16-07-25 04:32 AM, Rahul Lakkireddy wrote:
> > Hi Adrien,
> > 
> > On Thursday, July 07/21/16, 2016 at 19:07:38 +0200, Adrien Mazarguil wrote:
> >> Hi Rahul,
> >>
> >> Please see below.
> >>
> >> On Thu, Jul 21, 2016 at 01:43:37PM +0530, Rahul Lakkireddy wrote:
> >>> Hi Adrien,
> >>>
> >>> The proposal looks very good.  It satisfies most of the features
> >>> supported by Chelsio NICs.  We are looking for suggestions on exposing
> >>> more additional features supported by Chelsio NICs via this API.
> >>>
> >>> Chelsio NICs have two regions in which filters can be placed -
> >>> Maskfull and Maskless regions.  As their names imply, maskfull region
> >>> can accept masks to match a range of values; whereas, maskless region
> >>> don't accept any masks and hence perform a more strict exact-matches.
> >>> Filters without masks can also be placed in maskfull region.  By
> >>> default, maskless region have higher priority over the maskfull region.
> >>> However, the priority between the two regions is configurable.
> >>
> >> I understand this configuration affects the entire device. Just to be 
> >> clear,
> >> assuming some filters are already configured, are they affected by a change
> >> of region priority later?
> >>
> > 
> > Both the regions exist at the same time in the device.  Each filter can
> > either belong to maskfull or the maskless region.
> > 
> > The priority is configured at time of filter creation for every
> > individual filter and cannot be changed while the filter is still
> > active. If priority needs to be changed for a particular filter then,
> > it needs to be deleted first and re-created.
> 
> Could you model this as two tables and add a table_id to the API? This
> way user space could populate the table it chooses. We would have to add
> some capabilities attributes to "learn" if tables support masks or not
> though.
> 

This approach sounds interesting.

> I don't see how the PMD can sort this out in any meaningful way and it
> has to be exposed to the application that has the intelligence to 'know'
> priorities between masks and non-masks filters. I'm sure you could come
> up with something but it would be less than ideal in many cases I would
> guess and we can't have the driver getting priorities wrong or we may
> not get the correct behavior.
> 
> > 
> >>> Please suggest on how we can let the apps configure in which region
> >>> filters must be placed and set the corresponding priority accordingly
> >>> via this API.
> >>
> >> Okay. Applications, like customers, are always right.
> >>
> >> With this in mind, PMDs are not allowed to break existing flow rules, and
> >> face two options when applications provide a flow specification that would
> >> break an existing rule:
> >>
> >> - Refuse to create it (easiest).
> >>
> >> - Find a workaround to apply it anyway (possibly quite complicated).
> >>
> >> The reason you have these two regions is performance right? Otherwise I'd
> >> just say put everything in the maskfull region.
> >>
> > 
> > Unfortunately, our maskfull region is extremely small too compared to
> > maskless region.
> > 
> 
> To me this means a userspace application would want to pack it
> carefully to get the full benefit. So you need some mechanism to specify
> the "region" hence the above table proposal.
> 

Right. Makes sense.

[...]
> >> Now about this "promisc" match criteria, it can be added as a new meta
> >> pattern item (4.1.3 Meta item types). Do you want it to be defined from the
> >> start or add it later with the related code in your PMD?
> >>
> > 
> > It could be added as a meta item.  If there are other interested
> > parties, it can be added now.  Otherwise, we'll add it with our filtering
> > related code.
> > 
> 
> hmm I guess by "promisc" here you mean match packets received from the
> wire before they have been switched by the silicon?
> 

Match packets received from wire before they have been switched by
silicon, and which also includes packets not destined for DUT and were
still received due to interface being in promisc mode.

> >>> - Match FCoE packets.
> >>
> >> The "oE" part is covered by the ETH item (using the proper Ethertype), but 
> >> a
> >> new pattern item should probably be added for the FC protocol itself. As
> >> above, I suggest adding it later.
> >>
> > 
> > Same here.
> > 
> >>> - Match IP Fragmented packets.
> >>
> >> It seems that I missed quite a few fields in the IPv4 item definition
> >> (struct rte_flow_item_ipv4). It should be in there.
> >>
> > 
> > This raises another interesting question.  What should the PMD do
> > if it has support to only a subset of fields in the particular item?
> > 
> > For example, if a rule has been sent to match IP fragmentation along
> > with several other IPv4 fields, and if the underlying hardware doesn't
> > support matching based on IP fragmentation, does the PMD reject the
> > complete rule although it could have 

[dpdk-dev] Compiler hardening flags for libraries and performance implications

[Luca Boccassi]

Hello,

While working on uploading DPDK to Ubuntu and Debian, we were wondering
if anyone had any thoughts/opinions on enabling compiler hardening flags
for the DPDK libraries and the possible performance implications.

Especially 2 of the hardening options provided on Debian/Ubuntu [1]
explicitly cite performance implications:

- "bind now" (ld -z now), which forces to resolve all dynamic symbols
immediately at load
- "stack protector" (-fstack-protector-strong), which adds safety checks
against stack overwrites

Any opinions? Would anyone have reservations if we enabled all of these
in the packages that will be distributed in Ubuntu and Debian?

Thanks!

-- 
Kind regards,
Luca Boccassi

[1] https://wiki.debian.org/Hardening#Environment_variables

[dpdk-dev] [PATCH v2] ethdev: fix documentation for queue start/stop

[Mcnamara, John]

> -Original Message-
> From: Rao, Nikhil
> Sent: Tuesday, July 26, 2016 3:13 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Yigit, Ferruh ;
> Mcnamara, John ; Rao, Nikhil
> 
> Subject: [PATCH v2] ethdev: fix documentation for queue start/stop
> 
> Fix documentation for rte_eth_dev_tx/rx_queue_start/stop() functions
> 
> Fixes: 2de9f8551ff9 ("ethdev: fix documentation for queue start/stop")
> 
> Signed-off-by: Nikhil Rao 

Acked-by: John McNamara 

[dpdk-dev] [PATCH] doc: announce KNI ethtool removal

[Ferruh Yigit]

On 7/21/2016 5:41 PM, Thomas Monjalon wrote:
> 2016-07-21 16:41, Igor Ryzhov:
>> On Thu, Jul 21, 2016 at 4:33 PM, Ferruh Yigit 
>> wrote:
>>> On 7/20/2016 5:07 PM, Thomas Monjalon wrote:
 The out-of-tree kernel code must be avoided.
 Moreover there is no good reason to keep this legacy feature
 which is only partially supported.

 As described earlier in this plan:
   http://dpdk.org/ml/archives/dev/2016-July/043606.html
 it will help to keep PCI ids in PMD code.

 Signed-off-by: Thomas Monjalon 
> [...]
 +
 +* The ethtool support will be removed from KNI in 16.11.
 +  It is implemented only for igb and ixgbe.
 +  It is really hard to maintain because it requires some out-of-tree 
 kernel
 +  code to be duplicated in this kernel module.
 +  Removing this partial support will help to restrict the PCI id 
 definitions
 +  to the PMD code.
>>>
>>> KNI ethtool is functional and maintained, and it may have users!
>>>
>>> Why just removing it, specially without providing an alternative?
> 
> Because
> 1/ It is using the shared PCI ids that we want to move
> 2/ It has a poor support (igb/ixgbe) and makes users confused
> 3/ It is a big import of another version of igb/ixgbe drivers

I agree it is not the best design, but this is a functional piece of
code, and as long it keep maintained or completely replaced I am for
keeping it.

> About the point 1, if we decide to keep KNI ethtool, please could you
> duplicate the igb/ixgbe PCI ids in KNI?

Sure, I am not aware of exactly what needs to be done, please show me.

>>> Is is good time to discuss KCP again?
>>
>> I think good alternative is rte_ethtool library from ethtool sample
>> application.
> 
> Yes I think so.
> 
>> But I am wondering why this code is only in app, not in lib.
> 
> It is an example lib because we were not sure wether we wanted to
> support it. But maybe it is time to discuss its status and check
> if it can be integrated with other DPDK libs?
> 

[dpdk-dev] [PATCH v2] doc: add known issue about promiscuous mode for I40e VF

[Mcnamara, John]

> -Original Message-
> From: Guo, Jia
> Sent: Tuesday, July 26, 2016 3:24 AM
> To: Mcnamara, John 
> Cc: dev at dpdk.org; Guo, Jia 
> Subject: [PATCH v2] doc: add known issue about promiscuous mode for I40e
> VF
> 
> When use i40e linux kernel driver as host driver and DPDK handler the i40e
> VF, the promiscuous mode doesn't work in i40e VF. It is not supported by
> DPDK i40e VF driver right now.
> 
> Signed-off-by: Jeff Guo 
> ---
> v1->v2:
> - add singned-off and modify some format
> 
>  doc/guides/rel_notes/known_issues.rst | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/known_issues.rst
> b/doc/guides/rel_notes/known_issues.rst
> index 5ec1987..e907c22 100644
> --- a/doc/guides/rel_notes/known_issues.rst
> +++ b/doc/guides/rel_notes/known_issues.rst
> @@ -620,3 +620,25 @@ The last EAL argument is replaced by the program name
> in argv[]
> 
>  **Driver/Module**:
> Environment Abstraction Layer (EAL).
> +
> +
> +I40e VF can't receive the promiscuous unicast/multicast/broadcast packet.
> +-

The underline here is too short and generates a warning:

doc/guides/rel_notes/known_issues.rst:626: WARNING: Title underline too 
short.

I40e VF can't receive the promiscuous unicast/multicast/broadcast packet.
-

> +
> +**Description**:
> +   Use i40e linux kernel driver PF generate VF, and run testpmd, set
> Promiscuous mode and
> +   All multicast mode to be enabled, then send packet with unknown
> destination MAC address
> +   to VF, but VF can't receive the packet.


The text style and tense doesn't match the rest of the doc. I would suggest
something like:


I40e VF may not receive packets in promiscuous mode
---

**Description**:
   Promiscuous mode is not supported by the DPDK i40e VF driver when using the
   i40e Linux kernel driver as host driver.

**Implication**:
   The i40e VF does not receive packets when the destination MAC address is 
unknown.

**Resolution/Workaround**:
   Use a destination MAC address that matches the VF.

**Affected Environment/Platform**:
   All.

**Driver/Module**:
   Poll Mode Driver (PMD).

[dpdk-dev] [PATCH v3] doc: add section on tested platforms and nics and OSes

[Mcnamara, John]

> -Original Message-
> From: Pei, Yulong
> Sent: Tuesday, July 26, 2016 4:33 AM
> To: dev at dpdk.org; thomas.monjalon at 6wind.com
> Cc: Mcnamara, John ; Pei, Yulong
> 
> Subject: [PATCH v3] doc: add section on tested platforms and nics and OSes
> 
> Add new section on tested platforms and nics and OSes to the release
> notes.
> 
> Signed-off-by: Yulong Pei 
> ---
>  doc/guides/rel_notes/release_16_07.rst | 119
> ++---
>  1 file changed, 111 insertions(+), 8 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/release_16_07.rst
> b/doc/guides/rel_notes/release_16_07.rst
> index d00a6ed..52faa8f 100644
> --- a/doc/guides/rel_notes/release_16_07.rst
> +++ b/doc/guides/rel_notes/release_16_07.rst
> @@ -393,12 +393,51 @@ Tested Platforms
>  .. This section should contain a list of platforms that were tested with
> this
> release.
> 
> -   The format is:
> +#. SuperMicro 1U

Hi,

This patch is still removing some RST comments. It is best to leave them
in place.

John

[dpdk-dev] [PATCH] doc: fix incorrect path to testpmd app

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John
> Sent: Tuesday, July 26, 2016 2:57 PM
> To: Shreyansh Jain ; De Lara Guarch, Pablo
> 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: fix incorrect path to testpmd app
> 
> >
> >  .. code-block:: console
> >
> > -$RTE_SDK/$RTE_TARGET/build/app/testpmd
> > +$RTE_SDK/$RTE_TARGET/app/testpmd
> 
> The exe is actually two places after the build but the existing one in the
> docs looks correct, the one in "build" looks different to me:
> 
> $ find . -name testpmd | xargs ls -1
> ./x86_64-native-linuxapp-gcc/app/testpmd
> ./x86_64-native-linuxapp-gcc/build/app/test-pmd/testpmd
> 

Sorry, I misread the +/- on that. So the fix looks good.

Acked-by: John McNamara 

[dpdk-dev] [PATCH] doc: fix incorrect path to testpmd app

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shreyansh Jain
> Sent: Tuesday, July 26, 2016 2:32 PM
> To: De Lara Guarch, Pablo 
> Cc: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: fix incorrect path to testpmd app
> 
> Signed-off-by: Shreyansh Jain 
> ---
>  doc/guides/testpmd_app_ug/build_app.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/guides/testpmd_app_ug/build_app.rst
> b/doc/guides/testpmd_app_ug/build_app.rst
> index 7f32a7c..4c7cf2e 100644
> --- a/doc/guides/testpmd_app_ug/build_app.rst
> +++ b/doc/guides/testpmd_app_ug/build_app.rst
> @@ -58,4 +58,4 @@ The basic compilation steps are:
> 
>  .. code-block:: console
> 
> -$RTE_SDK/$RTE_TARGET/build/app/testpmd
> +$RTE_SDK/$RTE_TARGET/app/testpmd

The exe is actually two places after the build but the existing one in
the docs looks correct, the one in "build" looks different to me:

$ find . -name testpmd | xargs ls -1
./x86_64-native-linuxapp-gcc/app/testpmd
./x86_64-native-linuxapp-gcc/build/app/test-pmd/testpmd

John

[dpdk-dev] [PATCH] ethdev: fix documentation for queue start/stop functions

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nikhil P Rao
> Sent: Tuesday, July 26, 2016 1:37 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Rao, Nikhil 
> Subject: [dpdk-dev] [PATCH] ethdev: fix documentation for queue start/stop
> functions
> 
> From: nikhil.rao at intel.com
> 
> Fix documentation for rte_eth_dev_tx/rx_queue_start/stop() functions

Hi,

Thanks for this. Some comments below.


> 
> Signed-off-by: Nikhil Rao 
> ---
>  lib/librte_ether/rte_ethdev.h | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 022733e..d72fab9 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -2039,9 +2039,7 @@ int rte_eth_dev_socket_id(uint8_t port_id);  int
> rte_eth_dev_is_valid_port(uint8_t port_id);
> 
>  /*
> - * Allocate mbuf from mempool, setup the DMA physical address
> - * and then start RX for specified queue of a port. It is used
> - * when rx_deferred_start flag of the specified queue is true.
> + * Start specified RX queue of a port.

This change, more or less, reverts the change to this description added in 
commit 3111eae26e2296ec049e6dfc3c0c522d7b9e1c62.

I don't know if "Allocate mbuf from mempool, setup the DMA physical address"
is correct for all pmds so maybe that could be omitted. However, it is 
probably worth keeping the part about the rx_deferred_start flag.



>   *
>   * @param port_id
>   *   The port identifier of the Ethernet device
> @@ -2050,7 +2048,7 @@ int rte_eth_dev_is_valid_port(uint8_t port_id);
>   *   The value must be in the range [0, nb_rx_queue - 1] previously
> supplied
>   *   to rte_eth_dev_configure().
>   * @return
> - *   - 0: Success, the transmit queue is correctly set up.
> + *   - 0: Success, the receive queue is enabled.

+1 to this and the other changes.

John

[dpdk-dev] [PATCH] net/i40e: fix setting RSS in i40e_recv_scattered_pkts

[dumitru.ce...@gmail.com]

From: Dumitru Ceara 

The driver is incorrectly setting the RSS field in the last mbuf in
the packet chain instead of the first. Moreover, the last mbuf might
have already been freed if it only contained the Ethernet CRC.

Also, fix the call to i40e_rxd_build_fdir to store the fdir flags in
the first mbuf of the chain instead of the last.

Signed-off-by: Dumitru Ceara 
---
 drivers/net/i40e/i40e_rxtx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index d3cfb98..554d167 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1436,10 +1436,10 @@ i40e_recv_scattered_pkts(void *rx_queue,
i40e_rxd_pkt_type_mapping((uint8_t)((qword1 &
I40E_RXD_QW1_PTYPE_MASK) >> I40E_RXD_QW1_PTYPE_SHIFT));
if (pkt_flags & PKT_RX_RSS_HASH)
-   rxm->hash.rss =
+   first_seg->hash.rss =
rte_le_to_cpu_32(rxd.wb.qword0.hi_dword.rss);
if (pkt_flags & PKT_RX_FDIR)
-   pkt_flags |= i40e_rxd_build_fdir(, rxm);
+   pkt_flags |= i40e_rxd_build_fdir(, first_seg);

 #ifdef RTE_LIBRTE_IEEE1588
pkt_flags |= i40e_get_iee15888_flags(first_seg, qword1);
-- 
1.9.1

[dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse --lcores

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wei Dai
> Sent: Tuesday, July 26, 2016 10:52 AM
> To: dev at dpdk.org
> Cc: Dai, Wei 
> Subject: [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse 
> --lcores
> 
> local variable i is not referred by other codes in the function 
> eal_parse_lcores( ), so it can be removed.
> 
> Signed-off-by: Wei Dai 
> ---
>  lib/librte_eal/common/eal_common_options.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_options.c 
> b/lib/librte_eal/common/eal_common_options.c
> index 481c732..c5bf98c 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -578,7 +578,6 @@ eal_parse_lcores(const char *lcores)
>   struct rte_config *cfg = rte_eal_get_configuration();
>   static uint16_t set[RTE_MAX_LCORE];
>   unsigned idx = 0;
> - int i;
>   unsigned count = 0;
>   const char *lcore_start = NULL;
>   const char *end = NULL;
> @@ -593,9 +592,6 @@ eal_parse_lcores(const char *lcores)
>   /* Remove all blank characters ahead and after */
>   while (isblank(*lcores))
>   lcores++;
> - i = strlen(lcores);
> - while ((i > 0) && isblank(lcores[i - 1]))
> - i--;

I suppose originally it meant to do something  like that:
while ((i > 0) && isblank(lcores[i - 1]))
lcores[i--] = 0;

to get rid of blank characters at the end of the line, no?
Konstantin

> 
>   CPU_ZERO();
> 
> --
> 2.5.5

[dpdk-dev] [PATCH v3] doc: add section on tested platforms and nics and OSes

[Yulong Pei]

Add new section on tested platforms and nics and OSes to the release notes.

Signed-off-by: Yulong Pei 
---
 doc/guides/rel_notes/release_16_07.rst | 119 ++---
 1 file changed, 111 insertions(+), 8 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index d00a6ed..52faa8f 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -393,12 +393,51 @@ Tested Platforms
 .. This section should contain a list of platforms that were tested with this
release.

-   The format is:
+#. SuperMicro 1U

-   #. Platform name.
+   - BIOS: 1.0c
+   - Processor: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz

-  - Platform details.
-  - Platform details.
+#. SuperMicro 1U
+
+   - BIOS: 1.0a
+   - Processor: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
+   - Onboard NIC: Intel(R) X552/X557-AT (2x10G)
+
+ - Firmware-version: 0x81cf
+ - Device ID (PF/VF): 8086:15ad /8086:15a8
+
+   - kernel driver version: 4.2.5 (ixgbe)
+
+#. SuperMicro 2U
+
+   - BIOS: 1.0a
+   - Processor: Intel(R) Xeon(R) CPU E5-4667 v3 @ 2.00GHz
+
+#. Intel(R) Server board S2600GZ
+
+   - BIOS: SE5C600.86B.02.02.0002.122320131210
+   - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+#. Intel(R) Server board W2600CR
+
+   - BIOS: SE5C600.86B.02.01.0002.082220131453
+   - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+#. Intel(R) Server board S2600CWT
+
+   - BIOS: SE5C610.86B.01.01.0009.060120151350
+   - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+#. Intel(R) Server board S2600WTT
+
+   - BIOS: SE5C610.86B.01.01.0005.101720141054
+   - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+#. Intel(R) Server board S2600WTT
+
+   - BIOS: SE5C610.86B.11.01.0044.090120151156
+   - Processor: Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz


 Tested NICs
@@ -406,9 +445,73 @@ Tested NICs

 .. This section should contain a list of NICs that were tested with this 
release.

-   The format is:
+#. Intel(R) Ethernet Controller X540-AT2
+
+   - Firmware version: 0x8389
+   - Device id (pf): 8086:1528
+   - Driver version: 3.23.2 (ixgbe)
+
+#. Intel(R) 82599ES 10 Gigabit Ethernet Controller
+
+   - Firmware version: 0x61bf0001
+   - Device id (pf/vf): 8086:10fb / 8086:10ed
+   - Driver version: 4.0.1-k (ixgbe)
+
+#. Intel(R) Corporation Ethernet Connection X552/X557-AT 10GBASE-T
+
+   - Firmware version: 0x81cf
+   - Device id (pf/vf): 8086:15ad / 8086:15a8
+   - Driver version: 4.2.5 (ixgbe)
+
+#. Intel(R) Ethernet Converged Network Adapter X710-DA4 (4x10G)
+
+   - Firmware version: 5.04
+   - Device id (pf/vf): 8086:1572 / 8086:154c
+   - Driver version: 1.4.26 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter X710-DA2 (2x10G)
+
+   - Firmware version: 5.04
+   - Device id (pf/vf): 8086:1572 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter XL710-QDA1 (1x40G)
+
+   - Firmware version: 5.04
+   - Device id (pf/vf): 8086:1584 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter XL710-QDA2 (2X40G)
+
+   - Firmware version: 5.04
+   - Device id (pf/vf): 8086:1583 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Corporation I350 Gigabit Network Connection
+
+   - Firmware version: 1.48, 0x86e7
+   - Device id (pf/vf): 8086:1521 / 8086:1520
+   - Driver version: 5.2.13-k (igb)
+
+#. Intel(R) Ethernet Multi-host Controller FM1
+
+   - Firmware version: N/A
+   - Device id (pf/vf): 8086:15d0
+   - Driver version: 0.17.0.9 (fm10k)
+
+
+Tested OSes
+---
+
+.. This section should contain a list of OSes that were tested with this 
release.

-   #. NIC name.
+   - CentOS 7.0
+   - Fedora 23
+   - Fedora 24
+   - FreeBSD 10.3
+   - Red Hat Enterprise Linux 7.2
+   - SUSE Enterprise Linux 12
+   - Ubuntu 15.10
+   - Ubuntu 16.04 LTS
+   - Wind River Linux 8

-  - NIC details.
-  - NIC details.
-- 
2.1.0

[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes

[Take Ceara]

Hi Beilei,

On Tue, Jul 26, 2016 at 10:47 AM, Zhang, Helin  wrote:
> Hi Ceara
>
> For testpmd command line, txqflags = 0xf01 should be set for receiving 
> packets which needs more than one mbufs.
> I am not sure if it is helpful for you here. Please have a try!
>

Just tried, and it doesn't really help:
testpmd -c 1 -n 4 -w :01:00.3 -w :81:00.3 -- -i
--coremask=0x0 --rxq=2 --txq=2 --mbuf-size 1152 --txpkts 1024
--enable-rx-cksum --rss-udp --txqflags 0xf01

  src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
length=1024 - nb_segs=1 - RSS hash=0x0 - RSS queue=0x0 - (outer) L2
type: ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001
DIP=C0A8000A - (outer) L4 type: UDP - Tunnel type: Unknown - Inner L2
type: Unknown - Inner L3 type: Unknown - Inner L4 type: Unknown
 - Receive queue=0x0
  PKT_RX_RSS_HASH

As I was saying in my previous email the problem is that the RSS is
set in the last mbuf instead of the first:

http://dpdk.org/browse/dpdk/tree/drivers/net/i40e/i40e_rxtx.c#n1438

Even worse, the last rxm mbuf was already freed if it only contained
the CRC which had to be stripped:

http://dpdk.org/browse/dpdk/tree/drivers/net/i40e/i40e_rxtx.c#n1419

Regards,
Dumitru


> Regards,
> Helin
>
>> -Original Message-
>> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
>> Sent: Tuesday, July 26, 2016 4:38 PM
>> To: Xing, Beilei 
>> Cc: Zhang, Helin ; Wu, Jingjing > intel.com>;
>> dev at dpdk.org
>> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs
>> for some RX mbuf sizes
>>
>> Hi Beilei,
>>
>> On Mon, Jul 25, 2016 at 12:04 PM, Take Ceara 
>> wrote:
>> > Hi Beilei,
>> >
>> > On Mon, Jul 25, 2016 at 5:24 AM, Xing, Beilei  
>> > wrote:
>> >> Hi,
>> >>
>> >>> -Original Message-
>> >>> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
>> >>> Sent: Friday, July 22, 2016 8:32 PM
>> >>> To: Xing, Beilei 
>> >>> Cc: Zhang, Helin ; Wu, Jingjing
>> >>> ; dev at dpdk.org
>> >>> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for
>> >>> XL710/X710 NICs for some RX mbuf sizes
>> >>>
>> >>> I was using the test-pmd "txonly" implementation which sends fixed
>> >>> UDP packets from 192.168.0.1:1024 -> 192.168.0.2:1024.
>> >>>
>> >>> I changed the test-pmd tx_only code so that it sends traffic with
>> >>> incremental destination IP: 192.168.0.1:1024 -> [192.168.0.2,
>> >>> 192.168.0.12]:1024
>> >>> I also dumped the source and destination IPs in the "rxonly"
>> >>> pkt_burst_receive function.
>> >>> Then I see that packets are indeed sent to different queues but the
>> >>> mbuf->hash.rss value is still 0.
>> >>>
>> >>> ./testpmd -c 1 -n 4 -w :01:00.3 -w :81:00.3 -- -i
>> >>> --coremask=0x0 --rxq=16 --txq=16 --mbuf-size 1152 --txpkts 1024
>> >>> --enable-rx-cksum --rss-udp
>> >>>
>> >>> [...]
>> >>>
>> >>>  - Receive queue=0xf
>> >>>   PKT_RX_RSS_HASH
>> >>>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
>> >>> length=1024 - nb_segs=1 - RSS queue=0xa - (outer) L2 type: ETHER -
>> >>> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80006 -
>> >>> (outer)
>> >>> L4 type: UDP - Tunnel type: Unknown - RSS hash=0x0 - Inner L2 type:
>> >>> Unknown - RSS queue=0xf - RSS queue=0x7 - (outer) L2 type: ETHER -
>> >>> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80007 -
>> >>> (outer)
>> >>> L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner
>> >>> L3 type: Unknown - Inner L4 type: Unknown
>> >>>  - Receive queue=0x7
>> >>>   PKT_RX_RSS_HASH
>> >>>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - (outer) L2 type:
>> >>> ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80009
>> >>> -
>> >>> type=0x0800 - length=1024 - nb_segs=1 - Inner L3 type: Unknown -
>> >>> Inner
>> >>> L4 type: Unknown - RSS hash=0x0 - (outer) L4 type: UDP - Tunnel type:
>> >>> Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - RSS
>> >>> queue=0x7 - Inner L4 type: Unknown
>> >>>
>> >>> [...]
>> >>>
>> >>> testpmd> stop
>> >>>   --- Forward Stats for RX Port= 0/Queue= 0 -> TX Port= 1/Queue= 0
>> ---
>> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>> >>>   --- Forward Stats for RX Port= 0/Queue= 1 -> TX Port= 1/Queue= 1
>> ---
>> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
>> >>>   --- Forward Stats for RX Port= 0/Queue= 2 -> TX Port= 1/Queue= 2
>> ---
>> >>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
>> >>>   --- Forward Stats for RX Port= 0/Queue= 3 -> TX Port= 1/Queue= 3
>> ---
>> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>> >>>   --- Forward Stats for RX Port= 0/Queue= 4 -> TX Port= 1/Queue= 4
>> ---
>> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
>> >>>   --- Forward Stats for RX Port= 0/Queue= 5 -> TX Port= 1/Queue= 5
>> ---
>> >>>   RX-packets: 0  TX-packets: 32 

[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes

[Take Ceara]

Hi Beilei,

On Mon, Jul 25, 2016 at 12:04 PM, Take Ceara  wrote:
> Hi Beilei,
>
> On Mon, Jul 25, 2016 at 5:24 AM, Xing, Beilei  
> wrote:
>> Hi,
>>
>>> -Original Message-
>>> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
>>> Sent: Friday, July 22, 2016 8:32 PM
>>> To: Xing, Beilei 
>>> Cc: Zhang, Helin ; Wu, Jingjing >> intel.com>;
>>> dev at dpdk.org
>>> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 
>>> NICs
>>> for some RX mbuf sizes
>>>
>>> I was using the test-pmd "txonly" implementation which sends fixed UDP
>>> packets from 192.168.0.1:1024 -> 192.168.0.2:1024.
>>>
>>> I changed the test-pmd tx_only code so that it sends traffic with 
>>> incremental
>>> destination IP: 192.168.0.1:1024 -> [192.168.0.2,
>>> 192.168.0.12]:1024
>>> I also dumped the source and destination IPs in the "rxonly"
>>> pkt_burst_receive function.
>>> Then I see that packets are indeed sent to different queues but the
>>> mbuf->hash.rss value is still 0.
>>>
>>> ./testpmd -c 1 -n 4 -w :01:00.3 -w :81:00.3 -- -i
>>> --coremask=0x0 --rxq=16 --txq=16 --mbuf-size 1152 --txpkts 1024
>>> --enable-rx-cksum --rss-udp
>>>
>>> [...]
>>>
>>>  - Receive queue=0xf
>>>   PKT_RX_RSS_HASH
>>>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
>>> length=1024 - nb_segs=1 - RSS queue=0xa - (outer) L2 type: ETHER -
>>> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80006 - (outer)
>>> L4 type: UDP - Tunnel type: Unknown - RSS hash=0x0 - Inner L2 type:
>>> Unknown - RSS queue=0xf - RSS queue=0x7 - (outer) L2 type: ETHER -
>>> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80007 - (outer)
>>> L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner
>>> L3 type: Unknown - Inner L4 type: Unknown
>>>  - Receive queue=0x7
>>>   PKT_RX_RSS_HASH
>>>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - (outer) L2 type:
>>> ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80009 -
>>> type=0x0800 - length=1024 - nb_segs=1 - Inner L3 type: Unknown - Inner
>>> L4 type: Unknown - RSS hash=0x0 - (outer) L4 type: UDP - Tunnel type:
>>> Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - RSS
>>> queue=0x7 - Inner L4 type: Unknown
>>>
>>> [...]
>>>
>>> testpmd> stop
>>>   --- Forward Stats for RX Port= 0/Queue= 0 -> TX Port= 1/Queue= 0 
>>> ---
>>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 1 -> TX Port= 1/Queue= 1 
>>> ---
>>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 2 -> TX Port= 1/Queue= 2 
>>> ---
>>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 3 -> TX Port= 1/Queue= 3 
>>> ---
>>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 4 -> TX Port= 1/Queue= 4 
>>> ---
>>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 5 -> TX Port= 1/Queue= 5 
>>> ---
>>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 6 -> TX Port= 1/Queue= 6 
>>> ---
>>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 7 -> TX Port= 1/Queue= 7 
>>> ---
>>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 8 -> TX Port= 1/Queue= 8 
>>> ---
>>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue= 9 -> TX Port= 1/Queue= 9 
>>> ---
>>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue=10 -> TX Port= 1/Queue=10 
>>> ---
>>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue=11 -> TX Port= 1/Queue=11 
>>> ---
>>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue=12 -> TX Port= 1/Queue=12 
>>> ---
>>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue=13 -> TX Port= 1/Queue=13 
>>> ---
>>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue=14 -> TX Port= 1/Queue=14 
>>> ---
>>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
>>>   --- Forward Stats for RX Port= 0/Queue=15 -> TX Port= 1/Queue=15 
>>> ---
>>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
>>>   -- Forward statistics for port 0  
>>> --
>>>   RX-packets: 428RX-dropped: 84

[dpdk-dev] usages issue with external mempool

[Hemant Agrawal]

Hi,
   There was lengthy discussions w.r.t external mempool patches. 
However, I am still finding usages issue with the agreed approach.

The existing API to create packet mempool, "rte_pktmbuf_pool_create" does not 
provide the option to change the object init iterator. This may be the reason 
that many applications (e.g. OVS) are using rte_mempool_create to create packet 
mempool  with their own object iterator (e.g. ovs_rte_pktmbuf_init).

e.g the existing usages are:
dmp->mp = rte_mempool_create(mp_name, mp_size, MBUF_SIZE(mtu),
 MP_CACHE_SZ,
 sizeof(struct rte_pktmbuf_pool_private),
 rte_pktmbuf_pool_init, NULL,
 ovs_rte_pktmbuf_init, NULL,
socket_id, 0);


With the new API set for packet pool create, this need to be changed to:

dmp->mp = rte_mempool_create_empty(mp_name, mp_size, MBUF_SIZE(mtu),
 MP_CACHE_SZ,
 sizeof(struct rte_pktmbuf_pool_private),
 socket_id, 0);
  if (dmp->mp == NULL)
 break;

  rte_errno = rte_mempool_set_ops_byname(dmp-mp,

RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
  if (rte_errno != 0) {
 RTE_LOG(ERR, MBUF, "error setting 
mempool handler\n");
 return NULL;
  }
  rte_pktmbuf_pool_init(dmp->mp, NULL);

  ret = rte_mempool_populate_default(dmp->mp);
  if (ret < 0) {
 rte_mempool_free(dmp->mp);
 rte_errno = -ret;
 return NULL;
  }

  rte_mempool_obj_iter(dmp->mp, 
ovs_rte_pktmbuf_init, NULL);

This is not a user friendly approach to ask for changing 1 API to 6 new APIs. 
Or, am I missing something?

I think, we should do one of the following:

1. Enhance "rte_pktmbuf_pool_create" to optionally accept "rte_mempool_obj_cb_t 
*obj_init, void *obj_init_arg" as inputs. If obj_init is not present, default 
can be used.
2. Create a new wrapper API (e.g. e_pktmbuf_pool_create_new) with  the above 
said behavior e.g.:
/* helper to create a mbuf pool */
struct rte_mempool *
rte_pktmbuf_pool_create_new(const char *name, unsigned n,
   unsigned cache_size, uint16_t priv_size, uint16_t data_room_size,
rte_mempool_obj_cb_t *obj_init, void *obj_init_arg,
   int socket_id)
3. Let the existing rte_mempool_create accept flag as "MEMPOOL_F_HW_PKT_POOL". 
Obviously, if this flag is set - all other flag values should be ignored. This 
was discussed earlier also.

Please share your opinion.

Regards,
Hemant

[dpdk-dev] [PATCH] net/i40e: fiX statstic inconsistent when port stopped

[Wei Zhao1]

rx_good_bytes and rx_good_packets statstic is inconsistent when port 
stopped,ipackets statistic is minus the discard packets but rx_bytes statistic 
not.
Also,i40e has no statstic of discard bytes, so we have to delete discard 
packets item from rx_good_packets statstic.

Fixes: 9aace75fc82e ("i40e: fix statistics")

Signed-off-by: Wei Zhao1 
---
 drivers/net/i40e/i40e_ethdev.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 11a5804..553dfd9 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2319,8 +2319,7 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, struct 
rte_eth_stats *stats)

stats->ipackets = pf->main_vsi->eth_stats.rx_unicast +
pf->main_vsi->eth_stats.rx_multicast +
-   pf->main_vsi->eth_stats.rx_broadcast -
-   pf->main_vsi->eth_stats.rx_discards;
+   pf->main_vsi->eth_stats.rx_broadcast;
stats->opackets = pf->main_vsi->eth_stats.tx_unicast +
pf->main_vsi->eth_stats.tx_multicast +
pf->main_vsi->eth_stats.tx_broadcast;
-- 
2.5.5

[dpdk-dev] Compiler hardening flags for libraries and performance implications

[Matthew Hall]

On Tue, Jul 26, 2016 at 02:53:13PM +, Luca Boccassi wrote:
> While working on uploading DPDK to Ubuntu and Debian, we were wondering
> if anyone had any thoughts/opinions on enabling compiler hardening flags
> for the DPDK libraries and the possible performance implications.

Most of the C profilers, both VTune and Perf based tools, have not given me 
that much helpful data. They make it very hard to go from slow functions down 
to actual slow lines of code causing performance issues that I should fix. So 
I would love to see a MUCH better DPDK tuning guide, because the current one 
is really generic and gives no useful advice beyond what any programmer has 
already heard many times that doesn't really add much value.

This issue aside, in general I found that all the bounds-checking stuff, 
various FORTIFY_SOURCE items, and other supposedly "helpful" code security 
functions were chewing up a lot of CPU resources in the profiling output, and 
obscuring the actual slow parts of code being executed in the profiling runs. 
This stuff was making it difficult for me to optimize my code effectively, 
because they replace readable things which exist in real files and have 
symbols with wrappers that don't have working symbols and such.

> Any opinions? Would anyone have reservations if we enabled all of these
> in the packages that will be distributed in Ubuntu and Debian?

Based on the bad stuff that happened to me, I had to disable all these things 
to get useful results and start making the code run faster. But it would be 
nice to have some better advice on profilers and do some actual measurements 
before-and-after to see if my experiences are repeatable.

Matthew.

[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes

[Ananyev, Konstantin]

Hi Dumitru,

> 
> Hi Beilei,
> 
> On Mon, Jul 25, 2016 at 12:04 PM, Take Ceara  
> wrote:
> > Hi Beilei,
> >
> > On Mon, Jul 25, 2016 at 5:24 AM, Xing, Beilei  
> > wrote:
> >> Hi,
> >>
> >>> -Original Message-
> >>> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
> >>> Sent: Friday, July 22, 2016 8:32 PM
> >>> To: Xing, Beilei 
> >>> Cc: Zhang, Helin ; Wu, Jingjing 
> >>> ; dev at dpdk.org
> >>> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for
> >>> XL710/X710 NICs for some RX mbuf sizes
> >>>
> >>> I was using the test-pmd "txonly" implementation which sends fixed 
> >>> UDP packets from 192.168.0.1:1024 -> 192.168.0.2:1024.
> >>>
> >>> I changed the test-pmd tx_only code so that it sends traffic with 
> >>> incremental destination IP: 192.168.0.1:1024 -> [192.168.0.2,
> >>> 192.168.0.12]:1024
> >>> I also dumped the source and destination IPs in the "rxonly"
> >>> pkt_burst_receive function.
> >>> Then I see that packets are indeed sent to different queues but 
> >>> the
> >>> mbuf->hash.rss value is still 0.
> >>>
> >>> ./testpmd -c 1 -n 4 -w :01:00.3 -w :81:00.3 -- -i
> >>> --coremask=0x0 --rxq=16 --txq=16 --mbuf-size 1152 --txpkts 
> >>> 1024 --enable-rx-cksum --rss-udp
> >>>
> >>> [...]
> >>>
> >>>  - Receive queue=0xf
> >>>   PKT_RX_RSS_HASH
> >>>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
> >>> length=1024 - nb_segs=1 - RSS queue=0xa - (outer) L2 type: ETHER -
> >>> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80006 -
> >>> (outer)
> >>> L4 type: UDP - Tunnel type: Unknown - RSS hash=0x0 - Inner L2 type:
> >>> Unknown - RSS queue=0xf - RSS queue=0x7 - (outer) L2 type: ETHER -
> >>> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80007 -
> >>> (outer)
> >>> L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - 
> >>> Inner
> >>> L3 type: Unknown - Inner L4 type: Unknown
> >>>  - Receive queue=0x7
> >>>   PKT_RX_RSS_HASH
> >>>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - (outer) L2 type:
> >>> ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 
> >>> DIP=C0A80009
> >>> -
> >>> type=0x0800 - length=1024 - nb_segs=1 - Inner L3 type: Unknown - 
> >>> Inner
> >>> L4 type: Unknown - RSS hash=0x0 - (outer) L4 type: UDP - Tunnel type:
> >>> Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - RSS
> >>> queue=0x7 - Inner L4 type: Unknown
> >>>
> >>> [...]
> >>>
> >>> testpmd> stop
> >>>   --- Forward Stats for RX Port= 0/Queue= 0 -> TX Port= 1/Queue= 0 
> >>> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 1 -> TX Port= 1/Queue= 1 
> >>> ---
> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 2 -> TX Port= 1/Queue= 2 
> >>> ---
> >>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 3 -> TX Port= 1/Queue= 3 
> >>> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 4 -> TX Port= 1/Queue= 4 
> >>> ---
> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 5 -> TX Port= 1/Queue= 5 
> >>> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 6 -> TX Port= 1/Queue= 6 
> >>> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 7 -> TX Port= 1/Queue= 7 
> >>> ---
> >>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 8 -> TX Port= 1/Queue= 8 
> >>> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 9 -> TX Port= 1/Queue= 9 
> >>> ---
> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue=10 -> TX Port= 1/Queue=10 
> >>> ---
> >>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue=11 -> TX Port= 1/Queue=11 
> >>> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue=12 -> TX Port= 1/Queue=12 
> >>> ---
> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue=13 -> TX Port= 1/Queue=13 
> >>> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue=14 -> TX Port= 1/Queue=14 
> >>> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 

[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes

[Zhang, Helin]

Hi Ceara

For testpmd command line, txqflags = 0xf01 should be set for receiving packets 
which needs more than one mbufs.
I am not sure if it is helpful for you here. Please have a try!

Regards,
Helin

> -Original Message-
> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
> Sent: Tuesday, July 26, 2016 4:38 PM
> To: Xing, Beilei 
> Cc: Zhang, Helin ; Wu, Jingjing  intel.com>;
> dev at dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs
> for some RX mbuf sizes
> 
> Hi Beilei,
> 
> On Mon, Jul 25, 2016 at 12:04 PM, Take Ceara 
> wrote:
> > Hi Beilei,
> >
> > On Mon, Jul 25, 2016 at 5:24 AM, Xing, Beilei  
> > wrote:
> >> Hi,
> >>
> >>> -Original Message-
> >>> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
> >>> Sent: Friday, July 22, 2016 8:32 PM
> >>> To: Xing, Beilei 
> >>> Cc: Zhang, Helin ; Wu, Jingjing
> >>> ; dev at dpdk.org
> >>> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for
> >>> XL710/X710 NICs for some RX mbuf sizes
> >>>
> >>> I was using the test-pmd "txonly" implementation which sends fixed
> >>> UDP packets from 192.168.0.1:1024 -> 192.168.0.2:1024.
> >>>
> >>> I changed the test-pmd tx_only code so that it sends traffic with
> >>> incremental destination IP: 192.168.0.1:1024 -> [192.168.0.2,
> >>> 192.168.0.12]:1024
> >>> I also dumped the source and destination IPs in the "rxonly"
> >>> pkt_burst_receive function.
> >>> Then I see that packets are indeed sent to different queues but the
> >>> mbuf->hash.rss value is still 0.
> >>>
> >>> ./testpmd -c 1 -n 4 -w :01:00.3 -w :81:00.3 -- -i
> >>> --coremask=0x0 --rxq=16 --txq=16 --mbuf-size 1152 --txpkts 1024
> >>> --enable-rx-cksum --rss-udp
> >>>
> >>> [...]
> >>>
> >>>  - Receive queue=0xf
> >>>   PKT_RX_RSS_HASH
> >>>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - type=0x0800 -
> >>> length=1024 - nb_segs=1 - RSS queue=0xa - (outer) L2 type: ETHER -
> >>> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80006 -
> >>> (outer)
> >>> L4 type: UDP - Tunnel type: Unknown - RSS hash=0x0 - Inner L2 type:
> >>> Unknown - RSS queue=0xf - RSS queue=0x7 - (outer) L2 type: ETHER -
> >>> (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80007 -
> >>> (outer)
> >>> L4 type: UDP - Tunnel type: Unknown - Inner L2 type: Unknown - Inner
> >>> L3 type: Unknown - Inner L4 type: Unknown
> >>>  - Receive queue=0x7
> >>>   PKT_RX_RSS_HASH
> >>>   src=68:05:CA:38:6D:63 - dst=02:00:00:00:00:01 - (outer) L2 type:
> >>> ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN SIP=C0A80001 DIP=C0A80009
> >>> -
> >>> type=0x0800 - length=1024 - nb_segs=1 - Inner L3 type: Unknown -
> >>> Inner
> >>> L4 type: Unknown - RSS hash=0x0 - (outer) L4 type: UDP - Tunnel type:
> >>> Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - RSS
> >>> queue=0x7 - Inner L4 type: Unknown
> >>>
> >>> [...]
> >>>
> >>> testpmd> stop
> >>>   --- Forward Stats for RX Port= 0/Queue= 0 -> TX Port= 1/Queue= 0
> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 1 -> TX Port= 1/Queue= 1
> ---
> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 2 -> TX Port= 1/Queue= 2
> ---
> >>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 3 -> TX Port= 1/Queue= 3
> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 4 -> TX Port= 1/Queue= 4
> ---
> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 5 -> TX Port= 1/Queue= 5
> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 6 -> TX Port= 1/Queue= 6
> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 7 -> TX Port= 1/Queue= 7
> ---
> >>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 8 -> TX Port= 1/Queue= 8
> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue= 9 -> TX Port= 1/Queue= 9
> ---
> >>>   RX-packets: 59 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue=10 -> TX Port= 1/Queue=10
> ---
> >>>   RX-packets: 48 TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue=11 -> TX Port= 1/Queue=11
> ---
> >>>   RX-packets: 0  TX-packets: 32 TX-dropped: 0
> >>>   --- Forward Stats for RX Port= 0/Queue=12 -> TX Port= 1/Queue=12
> ---
> >>>   RX-packets: 59 TX-packets: 32  

[dpdk-dev] [PATCH] mk: fix static link with glibc < 2.17

[Azarewicz, PiotrX T]

> > > The problem is that -lrt appears before -lrte_eal.
> > > The question is: where does it come from?
> > > It is even before _LDLIBS-y += -L$(RTE_SDK_BIN)/lib... mystery
> >
> > root cause:
> > commit  c7cda4d8b4ea9cb0f209dda36882d225354b1db9
> 
> The error is seen after this commit, yes.
> But I would not say it is the root cause.

Yes, you are right.

> The root cause is adding -lrt before other libs:
>   281948b4753e ("mk: fix missing librt dependencies")
> 
> > and my workaround is:
> > /app/test/Makefile
> >
> >  ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y)
> > -LDLIBS += -lrt
> >  SRCS-y += test_red.c
> >  SRCS-y += test_sched.c
> >  endif
> 
> Yes it is what I've done in this patch:
>   http://dpdk.org/patch/15008

Great, thanks.

[dpdk-dev] [PATCH v2] doc: add known issue about promiscuous mode for I40e VF

[Wu, Jingjing]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Guo
> Sent: Tuesday, July 26, 2016 10:24 AM
> To: Mcnamara, John
> Cc: dev at dpdk.org; Guo, Jia
> Subject: [dpdk-dev] [PATCH v2] doc: add known issue about promiscuous
> mode for I40e VF
> 
> When use i40e linux kernel driver as host driver and DPDK handler the i40e
> VF, the promiscuous mode doesn't work in i40e VF. It is not supported by
> DPDK i40e VF driver right now.
> 
> Signed-off-by: Jeff Guo 
Acked-by: Jingjing Wu 

[dpdk-dev] [PATCH v2] net/i40e: fix vsi removing from tailq when release

[Peng, Yuan]

Tested-by: Peng Yuan 

- Test Commit: 6baf0eca5cfa068621ee15605159523918109661
- OS/Kernel: 4.5.7-202.fc23.x86_64
- GCC: gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC)

1. Bind 1 pf to igb_uio
2. use the pf to generate 2 VFs
3. rmmod i40evf
4. launch testpmd with PF with or without floating veb parameter, quit the 
testpmd for several times, and never see the core dump So it can fix the "core 
dump" issue.

Thank you.
Yuan.

-Original Message-
From: Wu, Jingjing 
Sent: Monday, July 25, 2016 1:36 PM
To: Zhang, Helin 
Cc: dev at dpdk.org; Wu, Jingjing ; Xing, Beilei 
; Peng, Yuan 
Subject: [PATCH v2] net/i40e: fix vsi removing from tailq when release

VSI structure need to be removed from TAILQ list when releasing.
But for the child VSI it will be removed again after the structure is freed. It 
will cause core dump when the DPDK i40e using as PF host driver.

This patch fixes it to only remove child VSI from TAILQ before send adminq 
command to remove it from hardware.

Fixes: 4861cde46116 ("i40e: new poll mode driver")
Fixes: 440499cf5376 ("net/i40e: support floating VEB")
Signed-off-by: Jingjing Wu 
---
v2 change:
 - add fix for floating veb case

 drivers/net/i40e/i40e_ethdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c 
index 11a5804..d0aeb70 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -4110,7 +4110,6 @@ i40e_vsi_release(struct i40e_vsi *vsi)
TAILQ_FOREACH_SAFE(vsi_list, >veb->head, list, temp) {
if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
return -1;
-   TAILQ_REMOVE(>veb->head, vsi_list, list);
}
i40e_veb_release(vsi->veb);
}
@@ -4119,7 +4118,6 @@ i40e_vsi_release(struct i40e_vsi *vsi)
TAILQ_FOREACH_SAFE(vsi_list, >floating_veb->head, list, 
temp) {
if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
return -1;
-   TAILQ_REMOVE(>floating_veb->head, vsi_list, list);
}
}

--
2.4.0

[dpdk-dev] [PATCH] timer: fix incorrect pending-list manipulation

[Hiroyuki Mikita]

Fixes: 9b15ba895b9f ("timer: use a skip list")

2016-07-23 7:05 GMT+09:00 Sanford, Robert :
>
>
> On 7/17/16 10:35 AM, "Hiroyuki Mikita"  wrote:
>
>>This commit fixes incorrect pending-list manipulation
>>when getting list of expired timers in rte_timer_manage().
>>
>>When timer_get_prev_entries() sets pending_head on prev,
>>the pending-list is broken.
>>The next of pending_head always becomes NULL.
>>In this depth level, it is not need to manipulate the list.
>>
>>Signed-off-by: Hiroyuki Mikita 
>>---
>> lib/librte_timer/rte_timer.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>>diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
>>index 3dcdab5..7457d32 100644
>>--- a/lib/librte_timer/rte_timer.c
>>+++ b/lib/librte_timer/rte_timer.c
>>@@ -543,6 +543,8 @@ void rte_timer_manage(void)
>>   /* break the existing list at current time point */
>>   timer_get_prev_entries(cur_time, lcore_id, prev);
>>   for (i = priv_timer[lcore_id].curr_skiplist_depth -1; i >= 0; i--) {
>>+  if (prev[i] == _timer[lcore_id].pending_head)
>>+  continue;
>>   priv_timer[lcore_id].pending_head.sl_next[i] =
>>   prev[i]->sl_next[i];
>>   if (prev[i]->sl_next[i] == NULL)
>>--
>>2.7.4
>>
>
> Acked-by: Robert Sanford 
>

[dpdk-dev] [PATCH] timer: remove unnecessary timer add call

[Hiroyuki Mikita]

Fixes: a4b7a5a45cf5 ("timer: fix race condition")

2016-07-23 7:06 GMT+09:00 Sanford, Robert :
>
>
> On 7/17/16 1:35 PM, "Hiroyuki Mikita"  wrote:
>
>>When timer_set_running_state() fails in rte_timer_manage(),
>>the failed timer is put back on pending-list.
>>In this case, another core tries to reset or stop the timer.
>>It does not need to be on pending-list
>>
>>Signed-off-by: Hiroyuki Mikita 
>>---
>> lib/librte_timer/rte_timer.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>>diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
>>index 3dcdab5..94878d3 100644
>>--- a/lib/librte_timer/rte_timer.c
>>+++ b/lib/librte_timer/rte_timer.c
>>@@ -562,10 +562,9 @@ void rte_timer_manage(void)
>>   pprev = >sl_next[0];
>>   } else {
>>   /* another core is trying to re-config this one,
>>-   * remove it from local expired list and put it
>>-   * back on the priv_timer[] skip list */
>>+   * remove it from local expired list
>>+   */
>>   *pprev = next_tim;
>>-  timer_add(tim, lcore_id, 1);
>>   }
>>   }
>>
>>--
>>2.7.4
>>
>
> Acked-by: Robert Sanford 
>

[dpdk-dev] [PATCH] timer: fix break list when timer_cb reset running timer

[Hiroyuki Mikita]

Fixes: a4b7a5a45cf5 ("timer: fix race condition")

2016-07-25 23:43 GMT+09:00 Thomas Monjalon :
> Hiroyuki, Robert,
> I would like to apply these patches quickly.
> Please could you provide some "Fixes:" line to know the origin
> of the bugs?
> Thanks
>

[dpdk-dev] [PATCH] vhost: fix off-by-one error on nr_desc check

[Yuanhan Liu]

On Mon, Jul 25, 2016 at 04:09:58PM +0200, Maxime Coquelin wrote:
> nr_desc is not an index but the number of descriptors,
> so can be equal to the virtqueue size.
> 
> Fixes: a436f53ebfeb ("vhost: avoid dead loop chain")
> 
> Cc: Yuanhan Liu 
> Signed-off-by: Maxime Coquelin 

Thanks for catching it!

> ---
> Hi Yuanhan,
> 
> I faced the bug while testing my indirect descriptor patch, it happens
> as soon as the number of chained descritors is above 2.
> 
> But the bug may in theory also be faced with normal descriptors,

In theory, yes, and only in one case, that there is a Tx has 256
descriptors chained. If that happens, I doubt things work well.
So I would say it just happens __in theory__.

> so it might
> be good to have it 16.07?

Even though, it apparently fixes a bug, so I think we could have it
for 16.07.

Acked-by: Yuanhan Liu 

--yliu

[dpdk-dev] [PATCH] timer: fix break list when timer_cb reset running timer

[Hiroyuki Mikita]

Hi Robert,

My application had timers which reset another timer and sometimes did not work.
Its profile by 'perf' command showed timer_add occupied 99.9% CPU. It
seemed that an infinite loop occurred in rte_timer.
I inspected timer codes and found that the main cause was a bug of the
patch 3. In this process, I also found the other bugs.

Regards,
Hiroyuki

[dpdk-dev] [PATCH] maintainers: add an entry for the stable branches

[Yuanhan Liu]

On Mon, Jul 25, 2016 at 04:38:03PM +0200, Thomas Monjalon wrote:
> This git tree will be used to backport some fixes from the
> master branch to maintain some "stable releases".
> The minor version number z will be incremented for these releases:
>   YY.MM.z
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: Yuanhan Liu 

--yliu