[dpdk-dev] [PATCH 2/2] doc: remove references to intel dpdk in linux_gsg

[Siobhan Butler]

Adjusted line lengths and removed references to Intel which
are no longer relevant in linux gsg.

Signed-off-by: Siobhan Butler 
---
 doc/guides/linux_gsg/build_dpdk.rst| 149 +--
 doc/guides/linux_gsg/build_sample_apps.rst | 146 +--
 doc/guides/linux_gsg/enable_func.rst   | 144 ++-
 doc/guides/linux_gsg/intro.rst |  37 +++---
 doc/guides/linux_gsg/quick_start.rst   |  57 +
 doc/guides/linux_gsg/sys_reqs.rst  | 182 +
 6 files changed, 423 insertions(+), 292 deletions(-)

diff --git a/doc/guides/linux_gsg/build_dpdk.rst 
b/doc/guides/linux_gsg/build_dpdk.rst
index ee6cb69..db452d5 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -28,17 +28,18 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-Compiling the Intel? DPDK Target from Source
-
+Compiling the DPDK Target from Source
+=

 .. note::

-Parts of this process can also be done using the setup script described in 
Chapter 6 of this document.
+Parts of this process can also be done using the setup script described in
+Chapter 6 of this document.

-Install the Intel? DPDK and Browse Sources
---
+Install the DPDK and Browse Sources
+---

-First, uncompress the archive and move to the uncompressed Intel? DPDK source 
directory:
+First, uncompress the archive and move to the uncompressed DPDK source 
directory:

 .. code-block:: console

@@ -47,20 +48,20 @@ First, uncompress the archive and move to the uncompressed 
Intel? DPDK source d
user at host:~/DPDK-$ ls
app/   config/   examples/   lib/   LICENSE.GPL   LICENSE.LGPL   Makefile   
mk/   scripts/   tools/

-The Intel? DPDK is composed of several directories:
+The DPDK is composed of several directories:

-*   lib: Source code of Intel? DPDK libraries
+*   lib: Source code of DPDK libraries

-*   app: Source code of Intel? DPDK applications (automatic tests)
+*   app: Source code of DPDK applications (automatic tests)

-*   examples: Source code of Intel? DPDK application examples
+*   examples: Source code of DPDK application examples

 *   config, tools, scripts, mk: Framework-related makefiles, scripts and 
configuration

-Installation of Intel? DPDK Target Environments

+Installation of DPDK Target Environments
+

-The format of a Intel? DPDK target is:
+The format of a DPDK target is:

 ARCH-MACHINE-EXECENV-TOOLCHAIN

@@ -74,8 +75,8 @@ where:

 *   TOOLCHAIN can be:  gcc,  icc

-The targets to be installed depend on the 32-bit and/or 64-bit packages and 
compilers installed on the host.
-Available targets can be found in the DPDK/config directory.
+The targets to be installed depend on the 32-bit and/or 64-bit packages and 
compilers
+installed on the host. Available targets can be found in the DPDK/config 
directory.
 The defconfig\_ prefix should not be used.

 .. note::
@@ -83,10 +84,12 @@ The defconfig\_ prefix should not be used.
 Configuration files are provided with the RTE_MACHINE optimization level 
set.
 Within the configuration files, the RTE_MACHINE configuration value is set 
to native,
 which means that the compiled software is tuned for the platform on which 
it is built.
-For more information on this setting, and its possible values, see the 
*Intel? DPDK Programmers Guide*.
+For more information on this setting, and its possible values, see the
+*DPDK Programmers Guide*.

-When using the Intel? C++ Compiler (icc), one of the following commands should 
be invoked for 64-bit or 32-bit use respectively.
-Notice that the shell scripts update the $PATH variable and therefore should 
not be performed in the same session.
+When using the Intel? C++ Compiler (icc), one of the following commands should 
be invoked
+for 64-bit or 32-bit use respectively. Notice that the shell scripts update the
+$PATH variable and therefore should not be performed in the same session.
 Also, verify the compiler's installation directory since the path may be 
different:

 .. code-block:: console
@@ -94,7 +97,8 @@ Also, verify the compiler's installation directory since the 
path may be differe
 source /opt/intel/bin/iccvars.sh intel64
 source /opt/intel/bin/iccvars.sh ia32

-To install and make targets, use the make install T= command in the 
top-level Intel? DPDK directory.
+To install and make targets, use the make install T= command in the 
top-level
+DPDK directory.

 For example, to compile a 64-bit target using icc, run:

@@ -122,9 +126,11 @@ To compile all 64-bit targets using both gcc and icc, use:

 .. note::

-The wildcard operator 

[dpdk-dev] [PATCH 1/2] doc: updated i40e enabling additonal fnct in gsg

[Siobhan Butler]

Updated the i40e Enabling Additional Functionality
section (5.7) of DPDK Getting Started Guide.

Signed-off-by: Siobhan Butler 

Signed-off-by: Helin Zhang 
---
 doc/guides/linux_gsg/enable_func.rst | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/doc/guides/linux_gsg/enable_func.rst 
b/doc/guides/linux_gsg/enable_func.rst
index ac12d51..00c6d9e 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -171,6 +171,10 @@ Please note that while using iommu=pt is compulsory for 
igb_uio driver, the vfio
 High Performance of Small Packets on 40G NIC
 

+As there might be firmware fixes for performance enhancement in latest version
+of firmware image, the firmware update might be needed for getting high 
performance.
+Check with the local Intel's Network Division application engineers for 
firmware updates.
+
 Enabling Extended Tag and Setting Max Read Request Size
 ~~~

@@ -198,3 +202,13 @@ Use 16 Bytes RX Descriptor Size

 As i40e PMD supports both 16 and 32 bytes RX descriptor sizes, and 16 bytes 
size can provide helps to high performance of small packets.
 Configuration of CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC in config files can be 
changed to use 16 bytes size RX descriptors.
+
+High Performance and per Packet Latency Tradeoff
+
+
+Due to the hardware design, the interrupt signal inside NIC is needed for per
+packet descriptor write-back. The minimum interval of interrupts could be set
+at compile time by CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL in configuration files.
+Though there is a default configuration, the interval could be tuned by the
+users with that configuration item depends on what the user cares about more,
+performance or per packet latency.
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH 0/2] doc: update to i40e enabling and gsg fixes

[Siobhan Butler]

Updated Enabling Additional Functionality section of Linux GSG.
Adjusted line lengths and removed redundant referances to Intel 
from Linux GSG.

Siobhan Butler (2):
  doc: updated i40e enabling additonal fnct in gsg
  doc: remove references to intel dpdk in linux_gsg

 doc/guides/linux_gsg/build_dpdk.rst| 149 +--
 doc/guides/linux_gsg/build_sample_apps.rst | 146 +--
 doc/guides/linux_gsg/enable_func.rst   | 158 -
 doc/guides/linux_gsg/intro.rst |  37 +++---
 doc/guides/linux_gsg/quick_start.rst   |  57 +
 doc/guides/linux_gsg/sys_reqs.rst  | 182 +
 6 files changed, 437 insertions(+), 292 deletions(-)

-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH v5 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

[Jijiang Liu]

Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and 
outer_l3_len field, and rework csum forward engine and i40e PMD due to  these 
changes.

Signed-off-by: Jijiang Liu 
---
 app/test-pmd/csumonly.c |   58 +--
 lib/librte_mbuf/rte_mbuf.h  |4 +-
 lib/librte_pmd_i40e/i40e_rxtx.c |   38 +
 3 files changed, 53 insertions(+), 47 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 9094967..33ef377 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -189,11 +189,12 @@ process_inner_cksums(void *l3_hdr, uint16_t ethertype, 
uint16_t l3_len,
} else {
if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM)
ol_flags |= PKT_TX_IP_CKSUM;
-   else
+   else {
ipv4_hdr->hdr_checksum =
rte_ipv4_cksum(ipv4_hdr);
+   ol_flags |= PKT_TX_IPV4;
+   }
}
-   ol_flags |= PKT_TX_IPV4;
} else if (ethertype == _htons(ETHER_TYPE_IPv6))
ol_flags |= PKT_TX_IPV6;
else
@@ -262,22 +263,23 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
outer_ethertype,
if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) {
ipv4_hdr->hdr_checksum = 0;

-   if ((testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) == 0)
+   if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
+   ol_flags |= PKT_TX_OUTER_IP_CKSUM;
+   else
ipv4_hdr->hdr_checksum = rte_ipv4_cksum(ipv4_hdr);
-   }
+   } else if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
+   ol_flags |= PKT_TX_OUTER_IPV6;

udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + outer_l3_len);
/* do not recalculate udp cksum if it was 0 */
if (udp_hdr->dgram_cksum != 0) {
udp_hdr->dgram_cksum = 0;
-   if ((testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) == 0) {
-   if (outer_ethertype == _htons(ETHER_TYPE_IPv4))
-   udp_hdr->dgram_cksum =
-   rte_ipv4_udptcp_cksum(ipv4_hdr, 
udp_hdr);
-   else
-   udp_hdr->dgram_cksum =
-   rte_ipv6_udptcp_cksum(ipv6_hdr, 
udp_hdr);
-   }
+   if (outer_ethertype == _htons(ETHER_TYPE_IPv4))
+   udp_hdr->dgram_cksum =
+   rte_ipv4_udptcp_cksum(ipv4_hdr, udp_hdr);
+   else
+   udp_hdr->dgram_cksum =
+   rte_ipv6_udptcp_cksum(ipv6_hdr, udp_hdr);
}

return ol_flags;
@@ -303,8 +305,7 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
outer_ethertype,
  * TESTPMD_TX_OFFLOAD_* in ports[tx_port].tx_ol_flags. They control
  * wether a checksum must be calculated in software or in hardware. The
  * IP, UDP, TCP and SCTP flags always concern the inner layer.  The
- * VxLAN flag concerns the outer IP and UDP layer (if packet is
- * recognized as a vxlan packet).
+ * VxLAN flag concerns the outer IP(if packet is recognized as a vxlan packet).
  */
 static void
 pkt_burst_checksum_forward(struct fwd_stream *fs)
@@ -320,7 +321,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
uint16_t i;
uint64_t ol_flags;
uint16_t testpmd_ol_flags;
-   uint8_t l4_proto;
+   uint8_t l4_proto, l4_tun_len = 0;
uint16_t ethertype = 0, outer_ethertype = 0;
uint16_t l2_len = 0, l3_len = 0, l4_len = 0;
uint16_t outer_l2_len = 0, outer_l3_len = 0;
@@ -360,6 +361,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)

ol_flags = 0;
tunnel = 0;
+   l4_tun_len = 0;
m = pkts_burst[i];

/* Update the L3/L4 checksum error packet statistics */
@@ -378,14 +380,16 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
if (l4_proto == IPPROTO_UDP) {
udp_hdr = (struct udp_hdr *)((char *)l3_hdr + l3_len);

+   /* check udp destination port, 4789 is the default
+* vxlan port (rfc7348) */
+   if (udp_hdr->dst_port == _htons(4789)) {
+   l4_tun_len = ETHER_VXLAN_HLEN;
+   tunnel = 1;
+
/* currently, this flag is set by i40e only if the
 * packet is vxlan */
-   if (((m->ol_flags & PKT_RX_TUNNEL_IPV4_HDR) ||
-   (m->ol_flags & PKT_RX_TUNNEL_IPV6_HDR)))
-   tunnel = 1;
- 

[dpdk-dev] [PATCH v5 2/3] mbuf:add three TX ol_flags and repalce PKT_TX_VXLAN_CKSUM

[Jijiang Liu]

Replace PKT_TX_VXLAN_CKSUM with PKT_TX_UDP_TUNNEL_PKT in order to indicate a 
packet is an UDP tunneling packet, and introduce 3 TX offload flags for outer 
IP TX checksum, which are PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV4 and 
PKT_TX_OUTER_IPV6 respectively;Rework csum forward engine and i40e PMD due to 
these changes.

Signed-off-by: Jijiang Liu 
---
 app/test-pmd/csumonly.c |9 +++--
 lib/librte_mbuf/rte_mbuf.c  |7 ++-
 lib/librte_mbuf/rte_mbuf.h  |   11 ++-
 lib/librte_pmd_i40e/i40e_rxtx.c |6 +++---
 4 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index d8c080a..9094967 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -257,7 +257,7 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
outer_ethertype,
uint64_t ol_flags = 0;

if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
-   ol_flags |= PKT_TX_VXLAN_CKSUM;
+   ol_flags |= PKT_TX_UDP_TUNNEL_PKT;

if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) {
ipv4_hdr->hdr_checksum = 0;
@@ -470,7 +470,12 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
{ PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK },
{ PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK },
{ PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK },
-   { PKT_TX_VXLAN_CKSUM, PKT_TX_VXLAN_CKSUM },
+   { PKT_TX_UDP_TUNNEL_PKT, PKT_TX_UDP_TUNNEL_PKT 
},
+   { PKT_TX_IPV4, PKT_TX_IPV4 },
+   { PKT_TX_IPV6, PKT_TX_IPV6 },
+   { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM 
},
+   { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4 },
+   { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6 },
{ PKT_TX_TCP_SEG, PKT_TX_TCP_SEG },
};
unsigned j;
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 87c2963..1b14e02 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -240,8 +240,13 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
case PKT_TX_SCTP_CKSUM: return "PKT_TX_SCTP_CKSUM";
case PKT_TX_UDP_CKSUM: return "PKT_TX_UDP_CKSUM";
case PKT_TX_IEEE1588_TMST: return "PKT_TX_IEEE1588_TMST";
-   case PKT_TX_VXLAN_CKSUM: return "PKT_TX_VXLAN_CKSUM";
+   case PKT_TX_UDP_TUNNEL_PKT: return "PKT_TX_UDP_TUNNEL_PKT";
case PKT_TX_TCP_SEG: return "PKT_TX_TCP_SEG";
+   case PKT_TX_IPV4: return "PKT_TX_IPV4";
+   case PKT_TX_IPV6: return "PKT_TX_IPV6";
+   case PKT_TX_OUTER_IP_CKSUM: return "PKT_TX_OUTER_IP_CKSUM";
+   case PKT_TX_OUTER_IPV4: return "PKT_TX_OUTER_IPV4";
+   case PKT_TX_OUTER_IPV6: return "PKT_TX_OUTER_IPV6";
default: return NULL;
}
 }
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index cbadf8e..6eb898f 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -118,7 +118,7 @@ extern "C" {
  */
 #define PKT_TX_TCP_SEG   (1ULL << 49)

-#define PKT_TX_VXLAN_CKSUM   (1ULL << 50) /**< TX checksum of VXLAN computed 
by NIC */
+#define PKT_TX_UDP_TUNNEL_PKT (1ULL << 50) /**< TX packet is an UDP tunneling 
packet */
 #define PKT_TX_IEEE1588_TMST (1ULL << 51) /**< TX IEEE1588 packet to 
timestamp. */

 /**
@@ -149,6 +149,15 @@ extern "C" {

 #define PKT_TX_VLAN_PKT  (1ULL << 57) /**< TX packet is a 802.1q VLAN 
packet. */

+/** Outer IP checksum of TX packet, computed by NIC for tunneling packet */
+#define PKT_TX_OUTER_IP_CKSUM   (1ULL << 58)
+
+/** Packet is outer IPv4 without requiring IP checksum offload for tunneling 
packet. */
+#define PKT_TX_OUTER_IPV4   (1ULL << 59)
+
+/** Tell the NIC it's an outer IPv6 packet for tunneling packet */
+#define PKT_TX_OUTER_IPV6(1ULL << 60)
+
 /* Use final bit of flags to indicate a control mbuf */
 #define CTRL_MBUF_FLAG   (1ULL << 63) /**< Mbuf contains control data */

diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 2d2ef04..078e973 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -478,7 +478,7 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
}

/* VXLAN packet TX checksum offload */
-   if (unlikely(ol_flags & PKT_TX_VXLAN_CKSUM)) {
+   if (unlikely(ol_flags & PKT_TX_UDP_TUNNEL_PKT)) {
uint8_t l4tun_len;

l4tun_len = ETHER_VXLAN_HLEN + inner_l2_len;
@@ -1158,8 +1158,8 @@ i40e_calc_context_desc(uint64_t flags)
 {
uint64_t mask = 0ULL;

-   if (flags | PKT_TX_VXLAN_CKSUM)
-   mask |= PKT_TX_VXLAN_CKSUM;
+   if (flags | PKT_TX_UDP_TUNNEL_PKT)
+   mask |= PKT_TX_UDP_TUNNEL_PKT;

 #ifdef RTE_LIBRTE_IEEE1588
mask |= PKT_TX_IEEE1588_TM

[dpdk-dev] [PATCH v5 1/3] mbuf:redefine three TX ol_flags

[Jijiang Liu]

The reason of redefining the PKT_TX_IPV4 and the PKT_TX_IPV6 is listed below,
It will avoid to send a packet with a bad info:
  - we receive a Ether/IP6/IP4/L4/data packet
  - the driver sets PKT_RX_IPV6_HDR
  - the stack decapsulates IP6
  - the stack sends the packet, it has the PKT_TX_IPV6 flag but it's an IPv4 
packet.

Signed-off-by: Jijiang Liu 
---
 lib/librte_mbuf/rte_mbuf.h |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 2e5fce5..cbadf8e 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -141,13 +141,13 @@ extern "C" {
 #define PKT_TX_IP_CKSUM  (1ULL << 54) /**< IP cksum of TX pkt. computed by 
NIC. */
 #define PKT_TX_IPV4_CSUM PKT_TX_IP_CKSUM /**< Alias of PKT_TX_IP_CKSUM. */

-/** Tell the NIC it's an IPv4 packet. Required for L4 checksum offload or TSO. 
*/
-#define PKT_TX_IPV4  PKT_RX_IPV4_HDR
+/** Packet is IPv4 without requiring IP checksum offload. */
+#define PKT_TX_IPV4  (1ULL << 55)

-/** Tell the NIC it's an IPv6 packet. Required for L4 checksum offload or TSO. 
*/
-#define PKT_TX_IPV6  PKT_RX_IPV6_HDR
+/** Tell the NIC it's an IPv6 packet.*/
+#define PKT_TX_IPV6  (1ULL << 56)

-#define PKT_TX_VLAN_PKT  (1ULL << 55) /**< TX packet is a 802.1q VLAN 
packet. */
+#define PKT_TX_VLAN_PKT  (1ULL << 57) /**< TX packet is a 802.1q VLAN 
packet. */

 /* Use final bit of flags to indicate a control mbuf */
 #define CTRL_MBUF_FLAG   (1ULL << 63) /**< Mbuf contains control data */
-- 
1.7.7.6

[dpdk-dev] [PATCH v5 0/3] i40e VXLAN TX checksum rework

[Jijiang Liu]

We have got some feedback about backward compatibility of VXLAN TX checksum 
offload API with 1G/10G NIC after the i40e VXLAN TX checksum codes were 
applied, so we have to rework the APIs on i40e, including the changes of mbuf, 
i40e PMD and csum forward engine.

The main changes in mbuf are as follows, in place of removing 
PKT_TX_VXLAN_CKSUM, we introduce 4 new flags: PKT_TX_OUTER_IP_CKSUM, 
PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV6 and PKT_TX_UDP_TUNNEL_PKT. Replace the 
inner_l2_len and the inner_l3_len field with the outer_l2_len and outer_l3_len 
field.

Let's use a few examples to demonstrate how to use these new flags and existing 
flags in rte_mbuf.h
Let say we have a tunnel packet: 
eth_hdr_out/ipv4_hdr_out/udp_hdr_out/vxlan_hdr/ehtr_hdr_in/ipv4_hdr_in/tcp_hdr_in.
 There could be several scenarios:

A) User requests HW offload for ipv4_hdr_out checksum.
He doesn't care is it a tunnelled packet or not. So he sets:

mb->l2_len = eth_hdr_out;
mb->l3_len = ipv4_hdr_out;
mb->ol_flags |= PKT_TX_IPV4_CSUM;

B) User is aware that it is a tunnelled packet and requests HW offload for 
ipv4_hdr_in and tcp_hdr_in *only*.
He doesn't care about outer IP checksum offload. In that case, for FVL  he has 
2 choices:
   1. Treat that packet as a 'proper' tunnelled packet, and fill all the fields:
 mb->l2_len = udp_hdr_out + vxlan_hdr +eth_hdr_in;
 mb->l3_len = ipv4_hdr_in;
 mb->outer_l2_len = eth_hdr_out;
 mb->outer_l3_len = ipv4_hdr_out;
 mb->ol_flags |= PKT_TX_UDP_TUNNEL_PKT | PKT_TX_IP_CKSUM |  
PKT_TX_TCP_CKSUM;

   2. As user doesn't care about outer IP hdr checksum, he can treat everything 
before ipv4_hdr_in as L2 header.
   So he knows, that it is a tunnelled packet, but makes HW to treat it as 
ordinary (non-tunnelled) packet:
 mb->l2_len = eth_hdr_out + ipv4_hdr_out + udp_hdr_out + vxlan_hdr + 
ehtr_hdr_in;
 mb->l3_len = ipv4_hdr_in;
 mb->ol_flags |= PKT_TX_IP_CKSUM |  PKT_TX_TCP_CKSUM;

i40e PMD will support both B.1 and B.2, but ixgbe/igb/em PMD supports only B.2.
if HW supports both - it will be up to user app which method to choose.
tespmd will support both methods, and it should be configurable by user which 
approach to use (cmdline parameter).
So the user can try/test both methods and select an appropriate for him.

C) User knows that is a tunnelled packet, and wants HW offload for all 3 
checksums:  outer IP hdr checksum, inner IP checksum, inner TCP checksum.
Then he has to setup all TX checksum fields:
 mb->l2_len =  udp_hdr_out + vxlan_hdr +eth_hdr_in;;
 mb->l3_len = ipv4_hdr_in;
 mb->outer_l2_len = eth_hdr_out;
 mb->outer_l3_len = ipv4_hdr_out;
 mb->ol_flags |= PKT_TX_OUT_IP_CKSUM  | PKT_TX_UDP_TUNNEL_PKT | 
PKT_TX_IP_CKSUM |  PKT_TX_TCP_CKSUM;

Change notes:
v2 changes:
 remove PKT_TX_IP_CKSUM alias.
 add PKT_TX_OUT_IP_CKSUM and PKT_TX_OUTER_IPV6 in rte_get_tx_ol_flag_name.
 spliting mbuf changes into two patches.
 fix MACLEN caculation issue in i40e driver
 fix some issues in csumonly.c
 change cover letter.
v3 changes:
 fix MACLEN caculation issue in i40e driver when non-tunneling packet 
v4 changes:
 reorganize patches to avoid compilation to be broken between patches.
 remove l4_tun_len from mbuf structure.
 add PKT_TX_OUTER_IPV4 to indicate no IP checksum offload requirement for 
tunneling packet.
 change i40e PMD and csum engine due to above changes.

v5 changes:
 according to Konstantin's comments, optimize process_outer_cksums() in 
order to avoid setting PKT_TX_OUTER_IPV4 flags for the case when user didn't 
enable TESTPMD_TX_OFFLOAD_VXLAN_CKSUM 

Jijiang Liu (3):
  Redefine PKT_TX_IPV4, PKT_TX_IPV6 and PKT_TX_VLAN_PKT;
  Replace PKT_TX_VXLAN_CKSUM with PKT_TX_UDP_TUNNEL_PKT, and add 3 TX flags, 
which are PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV4 and PKT_TX_OUTER_IPV6,and 
rework csum forward engine and i40e pmd due to these changes;
  Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and 
outer_l3_len field, and rework csum forward engine and i40e pmd due to  these 
changes;

 app/test-pmd/csumonly.c |   69 ++
 lib/librte_mbuf/rte_mbuf.c  |7 +++-
 lib/librte_mbuf/rte_mbuf.h  |   25 +
 lib/librte_pmd_i40e/i40e_rxtx.c |   44 +
 4 files changed, 86 insertions(+), 59 deletions(-)

-- 
1.7.7.6

[dpdk-dev] [PATCH] doc: patch to include vhost library UG section in PG

[Siobhan Butler]

As Vhost will be a library in DPDK 1.8, adding a new section to
Programmer's Guide to describe its use.

Signed-off-by: Siobhan Butler 

Signed-off-by: Huawei Xie 
---
 doc/guides/prog_guide/index.rst |   1 +
 doc/guides/prog_guide/vhost_lib.rst | 101 
 2 files changed, 102 insertions(+)
 create mode 100644 doc/guides/prog_guide/vhost_lib.rst

diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index e0ac8f4..6652cb4 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -106,6 +106,7 @@ Copyright ? 2012-2014, Intel Corporation. All rights 
reserved.
 power_man
 packet_classif_access_ctrl
 packet_framework
+vhost_lib
 source_org
 dev_kit_build_system
 dev_kit_root_make_help
diff --git a/doc/guides/prog_guide/vhost_lib.rst 
b/doc/guides/prog_guide/vhost_lib.rst
new file mode 100644
index 000..68d2d26
--- /dev/null
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -0,0 +1,101 @@
+..  BSD LICENSE
+Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Vhost Library
+=
+
+The vhost cuse (cuse: user space character device driver) library implements a
+vhost cuse driver. It also creates, manages and destroys vhost devices for
+corresponding virtio devices in the guest. Vhost supported vSwitch could 
register
+callbacks to this library, which will be called when a vhost device is 
activated
+or deactivated by guest virtual machine.
+
+Vhost API Overview
+--
+
+*   Vhost driver registration
+
+  rte_vhost_driver_register registers the vhost cuse driver into the 
system.
+  Character device file will be created in the /dev directory.
+  Character device name is specified as the parameter.
+
+*   Vhost session start 
+
+  rte_vhost_driver_session_start starts the vhost session loop.
+  Vhost cuse session is an infinite blocking loop.
+  Put the session in a dedicate DPDK thread.
+
+*   Callback register
+
+  Vhost supported vSwitch could call rte_vhost_driver_callback_register to
+  register two callbacks, new_destory and destroy_device.
+  When virtio device is activated or deactivated by guest virtual machine,
+  the callback will be called, then vSwitch could put the device onto data
+  core or remove the device from data core.
+
+*   Read/write packets from/to guest virtual machine
+
+  rte_vhost_enqueue_burst transmit host packets to guest.
+  rte_vhost_dequeue_burst receives packets from guest.
+
+*   Feature enable/disable
+
+  Now one negotiate-able feature in vhost is merge-able.
+  vSwitch could enable/disable this feature for performance consideration.
+
+Vhost Implementation
+
+
+When vSwitch registers the vhost driver, it will register a cuse device driver
+into the system and creates a character device file. This cuse driver will
+receive vhost open/release/IOCTL message from QEMU simulator.
+
+When the open call is received, vhost driver will create a vhost device for the
+virtio device in the guest.
+
+When VHOST_SET_MEM_TABLE IOCTL is received, vhost searches the memory region
+to find the starting user space virtual address that maps the memory of guest
+virtual machine. Through this virtual address and the QEMU pid, vhost could
+find the file QEMU uses to map the guest memory. Vhost maps this file into its
+address space

[dpdk-dev] [PATCH v2 8/8] doc: updating the list of sample apps in rel notes

[Siobhan Butler]

Added new and existing names of sample apps to list of
sample apps in release notes.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/rel_description.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/rel_notes/rel_description.rst 
b/doc/guides/rel_notes/rel_description.rst
index 1dc3107..89adcd2 100644
--- a/doc/guides/rel_notes/rel_description.rst
+++ b/doc/guides/rel_notes/rel_description.rst
@@ -127,10 +127,14 @@ The following is a list of DPDK documents in the 
suggested reading order:

 *   L3 Forwarding

+*   L3 Forwarding with Access Control
+
 *   L3 Forwarding with Power Management

 *   L3 Forwarding in a Virtualized Environment

+*   Link Status Interrupt
+
 *   Load Balancing

 *   Multi-process
@@ -155,6 +159,8 @@ The following is a list of DPDK documents in the suggested 
reading order:

 *   Kernel NIC Interface (KNI)

+*   Distributor
+
 In addition, there are some other applications that are built when the 
libraries are created.
 The source for these applications is in the DPDK/app directory and are 
called:

-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH v2 7/8] doc: updated resolved issues with old known issues

[Siobhan Butler]

Removed resolved issues from known issues section.
Added new resolved issues to resolved issues section.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/known_issues.rst| 225 ---
 doc/guides/rel_notes/resolved_issues.rst | 171 +++
 2 files changed, 171 insertions(+), 225 deletions(-)

diff --git a/doc/guides/rel_notes/known_issues.rst 
b/doc/guides/rel_notes/known_issues.rst
index 64782bc..40e88db 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -62,147 +62,6 @@ Pause Frame Forwarding does not work properly on igb
 || 
 |
 
++--+

-Running TestPMD with SRIOV in Domain U may cause it to hang when XENVIRT 
switch is on
--
-
-++--+
-| Title  | Running TestPMD with SRIOV in Domain U may 
cause it to hang when XENVIRT switch is on|
-|| 
 |
-++==+
-| Reference #| IXA00168949 
 |
-|| 
 |
-++--+
-| Description| When TestPMD is run with only SRIOV port 
???./testpmd -c f -n 4 -- -i??? , the following |
-|| error occurs:   
 |
-|| 
 |
-|| PMD: gntalloc: ioctl error  
 |
-|| 
 |
-|| EAL: Error - exiting with code: 1   
 |
-|| 
 |
-|| Cause: Creation of mbuf pool for socket 0 
failed |
-|| 
 |
-|| Then, alternately run SRIOV port and virtIO 
with testpmd:|
-|| 
 |
-|| testpmd -c f -n 4 -- -i 
 |
-|| 
 |
-|| testpmd -c f -n 4 --use-dev="eth_xenvirt0" 
-- -i |
-|| 
 |
-++--+
-| Implication| DomU will not be accessible after you 
repeat this action some times  |
-|| 
 |
-++--+
-| Resolution/ Workaround | Run testpmd with a 
"--total-num-mbufs=N(N<=3500)"|
-|| 
 |
-++--+
-| Affected Environment/ Platform | Fedora 16, 64 bits + Xen hypervisor 4.2.3 + 
Domain 0 kernel 3.10.0   |
-|| +Domain U kernel 3.6.11 
 |
-|| 
   

[dpdk-dev] [PATCH v2 6/8] doc: removed reference to Intel DPDK in Rel Notes

[Siobhan Butler]

Removed multiple references to Intel(R) DPDK where no longer
relevant.
Adjusted line lengths and fixed typos.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/faq.rst| 14 ++---
 doc/guides/rel_notes/known_issues.rst   | 25 -
 doc/guides/rel_notes/rel_description.rst| 64 +++--
 doc/guides/rel_notes/resolved_issues.rst| 86 ++---
 doc/guides/rel_notes/supported_features.rst |  4 +-
 doc/guides/rel_notes/supported_os.rst   |  4 +-
 doc/guides/rel_notes/updating_apps.rst  | 12 ++--
 7 files changed, 109 insertions(+), 100 deletions(-)

diff --git a/doc/guides/rel_notes/faq.rst b/doc/guides/rel_notes/faq.rst
index dfc34e6..27eddb1 100644
--- a/doc/guides/rel_notes/faq.rst
+++ b/doc/guides/rel_notes/faq.rst
@@ -36,7 +36,7 @@ When running the test application, I get ?EAL: 
map_all_hugepages(): open faile

 This is most likely due to the test application not being run with sudo to 
promote the user to a superuser.
 Alternatively, applications can also be run as regular user.
-For more information, please refer to *Intel? DPDK Getting Started Guide*.
+For more information, please refer to *DPDK Getting Started Guide*.

 If I want to change the number of TLB Hugepages allocated, how do I remove the 
original pages allocated?
 

@@ -49,7 +49,7 @@ If you look in the directory, you will see n number of 2M 
pages files. If you sp
 These are then placed in memory segments to get contiguous memory.

 If you need to change the number of pages, it is easier to first remove the 
pages. The tools/setup.sh script provides an option to do this.
-See the ?Quick Start Setup Script? section in the *Intel? DPDK Getting Started 
Guide* for more information.
+See the ?Quick Start Setup Script? section in the *DPDK Getting Started Guide* 
for more information.

 If I execute ?l2fwd -c f -m 64 ?n 3 -- -p 3?, I get the following output, 
indicating that there are no socket 0 hugepages to allocate the mbuf and ring 
structures to?
 
---
@@ -59,14 +59,14 @@ I have set up a total of 1024 Hugepages (that is, allocated 
512 2M pages to each
 The -m command line parameter does not guarantee that huge pages will be 
reserved on specific sockets. Therefore, allocated huge pages may not be on 
socket 0.
 To request memory to be reserved on a specific socket, please use the 
--socket-mem command-line parameter instead of -m.

-I am running a 32-bit Intel? DPDK application on a NUMA system, and sometimes 
the application initializes fine but cannot allocate memory. Why is that 
happening?
+I am running a 32-bit DPDK application on a NUMA system, and sometimes the 
application initializes fine but cannot allocate memory. Why is that happening?
 
-

 32-bit applications have limitations in terms of how much virtual memory is 
available, hence the number of hugepages they are able to allocate is also 
limited (1 GB per page size).
 If your system has a lot (>1 GB per page size) of hugepage memory, not all of 
it will be allocated.
 Due to hugepages typically being allocated on a local NUMA node, the hugepages 
allocation the application gets during the initialization depends on which
 NUMA node it is running on (the EAL does not affinitize cores until much later 
in the initialization process).
-Sometimes, the Linux OS runs the Intel? DPDK application on a core that is 
located on a different NUMA node from Intel? DPDK master core and
+Sometimes, the Linux OS runs the DPDK application on a core that is located on 
a different NUMA node from DPDK master core and
 therefore all the hugepages are allocated on the wrong socket.

 To avoid this scenario, either lower the amount of hugepage memory available 
to 1 GB per page size (or less), or run the application with taskset
@@ -102,7 +102,7 @@ Traditionally, there is a trade-off between throughput and 
latency. An applicati
 but the end-to-end latency of an average packet typically increases as a 
result.
 Similarly, the application can be tuned to have, on average, a low end-to-end 
latency at the cost of lower throughput.

-To achieve higher throughput, the Intel? DPDK attempts to aggregate the cost 
of processing each packet individually by processing packets in bursts.
+To achieve higher throughput, the DPDK attempts to aggregate the cost of 
processing each packet individually by processing packets in bursts.
 Using the testpmd application as an example, the ?burst? size can be set on 
the command line to a value of 16 (also the default value).
 This allows the application to request 16 pa

[dpdk-dev] [PATCH v2 5/8] doc: remove appendix a from release notes

[Siobhan Butler]

Removing Appendix A from Release Notes as Intel Licensing information is
no longer relevant in this document.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/appendices.rst | 324 
 doc/guides/rel_notes/index.rst  |  44 -
 2 files changed, 368 deletions(-)
 delete mode 100644 doc/guides/rel_notes/appendices.rst

diff --git a/doc/guides/rel_notes/appendices.rst 
b/doc/guides/rel_notes/appendices.rst
deleted file mode 100644
index 6dec2e1..000
--- a/doc/guides/rel_notes/appendices.rst
+++ /dev/null
@@ -1,324 +0,0 @@
-..  BSD LICENSE
-Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-* Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in
-the documentation and/or other materials provided with the
-distribution.
-* Neither the name of Intel Corporation nor the names of its
-contributors may be used to endorse or promote products derived
-from this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-Appendix A  Intel?  DPDK License Overview
-=
-
-
-The following describes the various licenses used by the Intel? Data Plane 
Development Kit (Intel? DPDK).
-The purpose of the Intel? DPDK is to prove the abilities of the Intel? 
architecture processors and to provide users with a strong set of examples, 
libraries and proof points.
-By placing the majority of this software under the BSD License, users may 
choose to use the Intel? as is, parts of it, or just the ideas for their 
programs.
-All code may be modified by the user to suit their project needs and 
requirements.
-
-.. note::
-
-The license in each source file takes precedence over this document, and 
should be used as the definitive license for that file.
-All users should seek their legal team's guidance with respect to the 
licensing used by the Intel? DPDK.
-
-
-
-The following table lists those files (or libraries) that are not under a BSD 
License. In some cases, these files are part of the standard Intel? DPDK 
release package,
-and in other cases may be a separate package that requires a separate download 
to be added to the Intel? DPDK. This document spells out those cases where 
possible.
-
-The sections following the table provide the various licenses used. Please 
note that copyright notices may change overtime.
-It is the responsibility of all users to understand these licenses and seek 
their legal team's guidance.
-
-The use of the GPLv2 License is confined to files in kernel loadable modules.
-
-The use of the Dual BSD/LGPLv2 License and Dual BSD/GPL License allows use 
with either free/open source software or with proprietary software in userspace.
-
-
-+---+--+--+
-| File  | Description  

| License  |
-|   |  

|  |
-+===+==+==+
-| igb_uio.c | **1st Released** 

| GPLv2 License Information

[dpdk-dev] [PATCH v2 4/8] Doc: Moved known issue 6.29 to resolved issues in Rel Notes

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/resolved_issues.rst | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/doc/guides/rel_notes/resolved_issues.rst 
b/doc/guides/rel_notes/resolved_issues.rst
index f9ddb7f..7e5e268 100644
--- a/doc/guides/rel_notes/resolved_issues.rst
+++ b/doc/guides/rel_notes/resolved_issues.rst
@@ -1192,3 +1192,33 @@ Packet reception issues when virtualization is enabled
 | Driver/Module   | Poll mode drivers  
   |
 | |
   |
 
+-+---+
+
+
+
+Double VLAN does not work on Intel? 40GbE ethernet contoller
+
+
++-+---+
+| Title   | Double VLAN does not work on Intel? 40GbE 
ethernet controller |
+| |
   |
++=+===+
+| Reference # | IXA00369908
   |
+| |
   |
++-+---+
+| Description | On Inter? 40 GbE ethernet controller 
double VLAN does not work.   |
+| | This was confirmed as a Firmware issue 
which will be fixed in later versions of   |
+| | firmware.  
   |
++-+---+
+| Implication | After setting double vlan to be enabled on 
a port, no packets can be transmitted out  |
+| | on that port.  
   |
++-+---+
+| Resolution/Workaround   | Resolved in latest release with firmware 
upgrade. |
+| |
   |
+| |
   |
++-+---+
+| Affected Environment/Platform   | All
   |
+| |
   |
++-+---+
+| Driver/Module   | Poll mode drivers  
   |
+| |
   |
++-+---+
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH v2 3/8] Doc: Added to known issue 6.10 and removed fixed issue 6.29 from Rel_Notes

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/known_issues.rst | 38 +++
 1 file changed, 7 insertions(+), 31 deletions(-)

diff --git a/doc/guides/rel_notes/known_issues.rst 
b/doc/guides/rel_notes/known_issues.rst
index 8ef654a..9601b01 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -338,6 +338,12 @@ Not all variants of supported NIC types have been used in 
testing
 || 
 |
 || The NIC device identifiers used during 
testing:  |
 || 
 |
+|| *   Intel? Ethernet Controller XL710 for 
40GbE QSFP+ [8086:1584] |
+|| 
 |
+|| *   Intel? Ethernet Controller XL710 for 
40GbE QSFP+ [8086:1583] |
+|| 
 |
+|| *   Intel? Ethernet Controller X710 for 
10GbE SFP+ [8086:1572]   |
+|| 
 |
 || *   Intel?? 82576 Gigabit Ethernet 
Controller [8086:10c9] |
 || 
 |
 || *   Intel?? 82576 Quad Copper Gigabit 
Ethernet Controller [8086:10e8] |
@@ -940,37 +946,7 @@ Ethertype filter could receive other packets 
(non-assigned) in Niantic
 || 
 |
 
++--+

-Double VLAN does not work on Intel?? 40G ethernet controller

-
-++--+
-| Title  | Double VLAN does not work on Intel??  40G 
ethernet controller |
-|| 
 |
-++==+
-| Reference #| IXA00386480 
 |
-|| 
 |
-++--+
-| Description| On Intel?? 40G Ethernet Controller: 
  |
-|| 
 |
-|| Double VLAN does not work. This was 
confirmed a firmware issue which will be fixed   |
-|| in later versions of firmware.  
 |
-|| 
 |
-++--+
-| Implication| After setting double vlan to be enabled on 
a port, no packets can be transmitted out |
-|| on that port.   
 |
-|| 
 |
-++--+
-| Resolution/ Workaround | None
 |
-|| 
 |
-++--+
-| Affected Environment/ Platform | All 
 

[dpdk-dev] [PATCH v2 2/8] Doc: Added "New Features" to release notes

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/new_features.rst | 24 
 1 file changed, 24 insertions(+)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index a93aa3c..aafd146 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -30,6 +30,30 @@

 New Features
 
+*   Link Bonding 

+*   Support for 802.3ad link aggregation (mode 4) and transmit load 
balancing (mode 5) to the link bonding library.
+
+*   Support for registration of link status change callbacks with link 
bonding devices.
+
+*   Support for slaves devices which do not support link status change 
interrupts in the link bonding library via a link status polling mechanism. 
+
+*   Poll Mode Driver - 40 GbE Controllers (librte_pmd_i40e)
+
+*   Support for Flow Director
+
+*   Support for ethertype filter
+
+*   Support RSS in VF
+
+*   Support configuring redirection table with different size from 1GbE 
and 10 GbE
+   
+   -   128/512 entries of 40GbE PF
+   
+   -   64 entries of 40GbE VF
+
+*   Support configuring hash functions
+
+*   Packet Distributor Sample Application 

 For further features supported in this release, see Chapter 3 Supported 
Features.
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH v2 1/8] Doc: Moved 1.7 "New Features" to "Supported Features" for 1.8 in Rel_Notes

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/new_features.rst   | 17 -
 doc/guides/rel_notes/supported_features.rst | 22 ++
 2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index 568d0c9..a93aa3c 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -31,22 +31,5 @@
 New Features
 

-*   Packet Distributor library for dynamic, single-packet at a time, load 
balancing
-
-*   IP fragmentation and reassembly library
-
-*   Support for IPv6 in IP fragmentation and reassembly sample applications
-
-*   Support for VFIO for mapping BARs and setting up interrupts
-
-*   Link Bonding PMD Library supporting round-robin, active backup, 
balance(layer 2, layer 2+3, and layer 3+4) and broadcast bonding modes
-
-*   Support zero copy mode RX/TX in user space vhost sample
-
-*   Support multiple queues in virtio-net PMD
-
-*   Support for Intel?? 40GbE Controllers
-
-*   Support NIC filters in addition to flow director for Intel?? 1GbE and 
10GbE Controllers

 For further features supported in this release, see Chapter 3 Supported 
Features.
diff --git a/doc/guides/rel_notes/supported_features.rst 
b/doc/guides/rel_notes/supported_features.rst
index c51eb26..5d5ba70 100644
--- a/doc/guides/rel_notes/supported_features.rst
+++ b/doc/guides/rel_notes/supported_features.rst
@@ -31,6 +31,28 @@
 Supported Features
 ==

+*   Packet Distributor library for dynamic, single-packet at a time, load 
balancing
+
+*   IP fragmentation and reassembly library
+
+*   Support for IPv6 in IP fragmentation and reassembly sample applications
+
+*   Support for VFIO for mapping BARs and setting up interrupts
+
+*   Link Bonding PMD Library supporting round-robin, active backup, 
balance(layer 2, layer 2+3, and layer 3+4) and broadcast bonding modes 
+
+*   Support zero copy mode RX/TX in user space vhost sample
+
+*   Support multiple queues in virtio-net PMD
+
+*   Support for Intel? 40GbE Controllers:
+
+*   Intel? XL710 40 Gigabit Ethernet Controller
+
+*   Intel? X710 40 Gigabit Ethernet Controller
+
+*   Support NIC filters in addition to flow director for Intel? 1GbE and 10GbE 
Controllers
+
 *   Virtualization (KVM)

 *   Userspace vhost switch:
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH v2 0/8] doc: patch set to update release notes

[Siobhan Butler]

New Features section:
   - Removed 1.7 New Features 
   - Added 1.8.0 New Features
Supported Features section:
   - Added 1.7 features to Supported Features
Known Issues:
   - Added devices to Known issue "Not all varients of supported NIC types have 
been used in testing"
   - Removed known issue 6.29 "Double VLAN not working on 40GbE Ethnet 
Controller" as resolved
Resolved issues:
   - Added known issue 6.29 to resolved issues 
Removed references across all sections to Intel DPDK where no longer relevant.
Added new sample apps to sample apps list in release notes.
Moved issues newly resolved from known issues to resolved issues.
Removed Intel Licensing Appendix A as no longer relevant. 

Siobhan Butler (8):
  Doc: Moved 1.7 "New Features" to "Supported Features" for 1.8 in
Rel_Notes
  Doc: Added "New Features" to release notes
  Doc: Added to known issue 6.10 and removed fixed issue 6.29 from
Rel_Notes
  Doc: Moved known issue 6.29 to resolved issues in Rel Notes
  doc: remove appendix a from release notes
  doc: removed reference to Intel DPDK in Rel Notes
  doc: updated resolved issues with old known issues
  doc: updating the list of sample apps in rel notes

 doc/guides/rel_notes/appendices.rst | 324 
 doc/guides/rel_notes/faq.rst|  14 +-
 doc/guides/rel_notes/index.rst  |  44 
 doc/guides/rel_notes/known_issues.rst   | 288 ++---
 doc/guides/rel_notes/new_features.rst   |  27 ++-
 doc/guides/rel_notes/rel_description.rst|  70 +++---
 doc/guides/rel_notes/resolved_issues.rst| 287 
 doc/guides/rel_notes/supported_features.rst |  26 ++-
 doc/guides/rel_notes/supported_os.rst   |   4 +-
 doc/guides/rel_notes/updating_apps.rst  |  12 +-
 10 files changed, 362 insertions(+), 734 deletions(-)
 delete mode 100644 doc/guides/rel_notes/appendices.rst

-- 
1.9.4.msysgit.2

[dpdk-dev] Assign randomly generated MAC address

[Alex Markuze]

Hi, I'm seeing this message on real_init. Running from an ESX VM with
Intel 82599 VF

Assign randomly generated MAC address 02:09:c0:88:05:c6

The result is that the NIC anti spoofing kills all my tx traffic and for
some reason jumbo frames fail to go out from the second vf that does work.

Can any one shed some light on the issue? what additional Info I should
provide?

Same code does run on a different host/vm, It seems that some configuration
is missing on the PF.

Thanks.

[dpdk-dev] Error running dpdk app: cannot open /dev/uio

[Malveeka Tewari]

Ohh ok .. thanks for the clarification :)

Malveeka

On Tue, Dec 2, 2014 at 5:36 PM, Qiu, Michael  wrote:

> On 12/3/2014 9:25 AM, Malveeka Tewari wrote:
> > I do have the uio and igb_uio modules loaded.
> > For my issue, I found a workaround by manually creating /dev/uio0
> > using mknod.
> > But I still get the vfio error.
> >
> > If I try "sudo modprobe vfio" but that gives an error that Module vfio
> > not found.
> > I tried looking for vfio.ko in the dpdk source tree as well but could
> > not find that module.
> > How can I install the vfio module?
>
> VFIO is supplied by kernel :)
> if you use uio then vfio can be ignored. It is just another way of
> things in new kernel(version > 3.6).
>
> Thanks,
> Michael
>
> >
> > Thanks!
> > Malveeka
> >
> >
> >
> > On Tue, Dec 2, 2014 at 5:12 PM, Qiu, Michael  > > wrote:
> >
> > Hi Malveeka,
> >
> > To be sure that you should have [uio, igb_uio] or [uio,
> > uio_pci_generic]
> > or [vfio] module loaded.
> >
> > Thanks,
> > Michael
> > On 12/3/2014 5:44 AM, Malveeka Tewari wrote:
> > > Hi
> > >
> > > I am trying to run the testpmd app as but I get the following
> > errors:
> > > EAL: VFIO could not be initialized
> > > EAL: Cannot open /dev/uio0: No such file or directory
> > > EAL: Error - exiting with code: 1
> > >   Cause: Requested device :07:00.0 cannot be used
> > >
> > > lsmod shows that the uio module is installed.
> > > Is there anything that's missing?
> > >
> > > Thanks!
> > > Malveeka
> > >
> > >
> > >
> > > Output on trying to run testpmd
> > >
> > > EAL: Detected 16 lcore(s)
> > > *EAL:   cannot open VFIO container, error 2 (No such file or
> > directory)*
> > > *EAL: VFIO support could not be initialized*
> > > EAL: Setting up memory...
> > > EAL: Ask a virtual area of 0x20 bytes
> > > EAL: Virtual area found at 0x7fe66ac0 (size = 0x20)
> > > EAL: Ask a virtual area of 0xffc0 bytes
> > > EAL: Virtual area found at 0x7fe56ae0 (size = 0xffc0)
> > > EAL: Ask a virtual area of 0x20 bytes
> > > EAL: Virtual area found at 0x7fe56aa0 (size = 0x20)
> > > EAL: Ask a virtual area of 0xfec0 bytes
> > > EAL: Virtual area found at 0x7fe46bc0 (size = 0xfec0)
> > > EAL: Ask a virtual area of 0x40 bytes
> > > EAL: Virtual area found at 0x7fe46b60 (size = 0x40)
> > > EAL: Ask a virtual area of 0x40 bytes
> > > EAL: Virtual area found at 0x7fe46b00 (size = 0x40)
> > > EAL: Ask a virtual area of 0x40 bytes
> > > EAL: Virtual area found at 0x7fe46aa0 (size = 0x40)
> > > EAL: Ask a virtual area of 0x40 bytes
> > > EAL: Virtual area found at 0x7fe46a40 (size = 0x40)
> > > EAL: Ask a virtual area of 0x40 bytes
> > > EAL: Virtual area found at 0x7fe469e0 (size = 0x40)
> > > EAL: Requesting 2048 pages of size 2MB from socket 0
> > > EAL: Requesting 2048 pages of size 2MB from socket 1
> > > EAL: TSC frequency is ~2266745 KHz
> > > EAL: Master core 3 is ready (tid=6cedb800)
> > > EAL: PCI device :07:00.0 on NUMA socket -1
> > > EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> > >
> > >
> > > *EAL: Cannot open /dev/uio0: No such file or directoryEAL: Error
> > - exiting
> > > with code: 1  Cause: Requested device :07:00.0 cannot be used*
> > >
> >
> >
>
>

[dpdk-dev] [PATCH] add one option memory-only for those secondary PRBs

[chixiaobo]

---
 lib/librte_eal/common/eal_common_options.c |  18 +++-
 lib/librte_eal/common/eal_internal_cfg.h   |   1 +
 lib/librte_eal/common/eal_options.h|   4 +-
 lib/librte_eal/linuxapp/eal/eal.c  | 137 +++--
 4 files changed, 89 insertions(+), 71 deletions(-)
 mode change 100644 => 100755 lib/librte_eal/common/eal_common_options.c
 mode change 100644 => 100755 lib/librte_eal/common/eal_internal_cfg.h
 mode change 100644 => 100755 lib/librte_eal/common/eal_options.h
 mode change 100644 => 100755 lib/librte_eal/linuxapp/eal/eal.c

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
old mode 100644
new mode 100755
index e2810ab..5ab4b87
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -85,6 +85,7 @@ eal_long_options[] = {
{OPT_XEN_DOM0, 0, 0, OPT_XEN_DOM0_NUM},
{OPT_CREATE_UIO_DEV, 1, NULL, OPT_CREATE_UIO_DEV_NUM},
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
+{OPT_MEMORY_ONLY, 0, NULL, OPT_MEMORY_ONLY_NUM},
{0, 0, 0, 0}
 };

@@ -126,6 +127,7 @@ eal_reset_internal_config(struct internal_config 
*internal_cfg)
internal_cfg->no_hpet = 1;
 #endif
internal_cfg->vmware_tsc_map = 0;
+internal_cfg->memory_only= 0;
 }

 /*
@@ -454,6 +456,10 @@ eal_parse_common_option(int opt, const char *optarg,
conf->process_type = eal_parse_proc_type(optarg);
break;

+   case OPT_MEMORY_ONLY_NUM:
+   conf->memory_only= 1;
+   break;
+
case OPT_MASTER_LCORE_NUM:
if (eal_parse_master_lcore(optarg) < 0) {
RTE_LOG(ERR, EAL, "invalid parameter for --"
@@ -525,9 +531,9 @@ eal_check_common_options(struct internal_config 
*internal_cfg)
 {
struct rte_config *cfg = rte_eal_get_configuration();

-   if (!lcores_parsed) {
-   RTE_LOG(ERR, EAL, "CPU cores must be enabled with options "
-   "-c or -l\n");
+   if (!lcores_parsed && !(internal_cfg->process_type == 
RTE_PROC_SECONDARY&& internal_cfg->memory_only) ) {
+   RTE_LOG(ERR, EAL, "For those processes without memory-only 
option, CPU cores "
+"must be enabled with options -c or -l\n");
return -1;
}
if (cfg->lcore_role[cfg->master_lcore] != ROLE_RTE) {
@@ -545,6 +551,11 @@ eal_check_common_options(struct internal_config 
*internal_cfg)
"specified\n");
return -1;
}
+   if ( internal_cfg->process_type != RTE_PROC_SECONDARY &&
+   internal_cfg->memory_only) {
+   RTE_LOG(ERR, EAL, "only secondary processes can specify 
memory-only option.\n");
+   return -1;
+   }
if (index(internal_cfg->hugefile_prefix, '%') != NULL) {
RTE_LOG(ERR, EAL, "Invalid char, '%%', in --"OPT_FILE_PREFIX" "
"option\n");
@@ -590,6 +601,7 @@ eal_common_usage(void)
   "  --"OPT_SYSLOG" : set syslog facility\n"
   "  --"OPT_LOG_LEVEL"  : set default log level\n"
   "  --"OPT_PROC_TYPE"  : type of this process\n"
+   "  --"OPT_MEMORY_ONLY": only use shared memory, valid only for 
secondary process."
   "  --"OPT_PCI_BLACKLIST", -b: add a PCI device in black list.\n"
   "   Prevent EAL from using this PCI device. The 
argument\n"
   "   format is .\n"
diff --git a/lib/librte_eal/common/eal_internal_cfg.h 
b/lib/librte_eal/common/eal_internal_cfg.h
old mode 100644
new mode 100755
index aac6abf..68b982c
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -85,6 +85,7 @@ struct internal_config {

unsigned num_hugepage_sizes;  /**< how many sizes on this system */
struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES];
+volatile unsigned memory_only;/**name);
-   solib->lib_handle = dlopen(solib->name, RTLD_NOW);
-   if (solib->lib_handle == NULL)
-   RTE_LOG(WARNING, EAL, "%s\n", dlerror());
-   }
-
-   eal_thread_init_master(rte_config.master_lcore);
-
-   RTE_LOG(DEBUG, EAL, "Master core %u is ready (tid=%x)\n",
-   rte_config.master_lcore, (int)thread_id);
-
-   if (rte_eal_dev_init() < 0)
-   rte_panic("Cannot init pmd devices\n");
-
-   RTE_LCORE_FOREACH_SLAVE(i) {
-
-   /*
-* create communication pipes between master thread
-* and children
-*/
-   if (pipe(lcore_config[i].pipe_master2slave) < 0)
-   rte_panic("Cannot create pipe\n");
-   if (pipe(lcore_config[i].pipe_slave2master) < 0)
-   rte_panic("Cannot create pipe\n");
-
-   lcore_config[i].state = WAIT;
-
-   /* c

[dpdk-dev] Error running dpdk app: cannot open /dev/uio

[Malveeka Tewari]

I do have the uio and igb_uio modules loaded.
For my issue, I found a workaround by manually creating /dev/uio0 using
mknod.
But I still get the vfio error.

If I try "sudo modprobe vfio" but that gives an error that Module vfio not
found.
I tried looking for vfio.ko in the dpdk source tree as well but could not
find that module.
How can I install the vfio module?

Thanks!
Malveeka



On Tue, Dec 2, 2014 at 5:12 PM, Qiu, Michael  wrote:

> Hi Malveeka,
>
> To be sure that you should have [uio, igb_uio] or [uio, uio_pci_generic]
> or [vfio] module loaded.
>
> Thanks,
> Michael
> On 12/3/2014 5:44 AM, Malveeka Tewari wrote:
> > Hi
> >
> > I am trying to run the testpmd app as but I get the following errors:
> > EAL: VFIO could not be initialized
> > EAL: Cannot open /dev/uio0: No such file or directory
> > EAL: Error - exiting with code: 1
> >   Cause: Requested device :07:00.0 cannot be used
> >
> > lsmod shows that the uio module is installed.
> > Is there anything that's missing?
> >
> > Thanks!
> > Malveeka
> >
> >
> >
> > Output on trying to run testpmd
> >
> > EAL: Detected 16 lcore(s)
> > *EAL:   cannot open VFIO container, error 2 (No such file or directory)*
> > *EAL: VFIO support could not be initialized*
> > EAL: Setting up memory...
> > EAL: Ask a virtual area of 0x20 bytes
> > EAL: Virtual area found at 0x7fe66ac0 (size = 0x20)
> > EAL: Ask a virtual area of 0xffc0 bytes
> > EAL: Virtual area found at 0x7fe56ae0 (size = 0xffc0)
> > EAL: Ask a virtual area of 0x20 bytes
> > EAL: Virtual area found at 0x7fe56aa0 (size = 0x20)
> > EAL: Ask a virtual area of 0xfec0 bytes
> > EAL: Virtual area found at 0x7fe46bc0 (size = 0xfec0)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe46b60 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe46b00 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe46aa0 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe46a40 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fe469e0 (size = 0x40)
> > EAL: Requesting 2048 pages of size 2MB from socket 0
> > EAL: Requesting 2048 pages of size 2MB from socket 1
> > EAL: TSC frequency is ~2266745 KHz
> > EAL: Master core 3 is ready (tid=6cedb800)
> > EAL: PCI device :07:00.0 on NUMA socket -1
> > EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> >
> >
> > *EAL: Cannot open /dev/uio0: No such file or directoryEAL: Error -
> exiting
> > with code: 1  Cause: Requested device :07:00.0 cannot be used*
> >
>
>

[dpdk-dev] [PATCH v4 2/2] lib/librte_pmd_i40e: add I40E_VFTA_IDX and I40E_VFTA__BIT macros for VFTA related operation

[Huawei Xie]

Add two macros I40E_VFTA_IDX and I40E_VFTA_BIT for vlan filter search and set.
Add vlan_id check in vlan filter search and set function.

Signed-off-by: Huawei Xie 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 17 ++---
 lib/librte_pmd_i40e/i40e_ethdev.h |  9 +
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 518597f..43b9448 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -4157,8 +4157,11 @@ i40e_find_vlan_filter(struct i40e_vsi *vsi,
 {
uint32_t vid_idx, vid_bit;

-   vid_idx = (uint32_t) ((vlan_id >> 5) & 0x7F);
-   vid_bit = (uint32_t) (1 << (vlan_id & 0x1F));
+   if (vlan_id > ETH_VLAN_ID_MAX)
+   return 0;
+
+   vid_idx = I40E_VFTA_IDX(vlan_id);
+   vid_bit = I40E_VFTA_BIT(vlan_id);

if (vsi->vfta[vid_idx] & vid_bit)
return 1;
@@ -4172,11 +4175,11 @@ i40e_set_vlan_filter(struct i40e_vsi *vsi,
 {
uint32_t vid_idx, vid_bit;

-   /* VFTA is 32-bits size array, each element contains 32 vlan bits, Find 
the
-*  element first, then find the bits it belongs to
-*/
-   vid_idx = (uint32_t) ((vlan_id >> 5) & 0x7F);
-   vid_bit = (uint32_t) (1 << (vlan_id & 0x1F));
+   if (vlan_id > ETH_VLAN_ID_MAX)
+   return;
+
+   vid_idx = I40E_VFTA_IDX(vlan_id);
+   vid_bit = I40E_VFTA_BIT(vlan_id);

if (on)
vsi->vfta[vid_idx] |= vid_bit;
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.h 
b/lib/librte_pmd_i40e/i40e_ethdev.h
index f99fbea..f913ea9 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.h
+++ b/lib/librte_pmd_i40e/i40e_ethdev.h
@@ -50,6 +50,15 @@
 #define I40E_DEFAULT_QP_NUM_FDIR  1
 #define I40E_UINT32_BIT_SIZE  (CHAR_BIT * sizeof(uint32_t))
 #define I40E_VFTA_SIZE(4096 / I40E_UINT32_BIT_SIZE)
+/*
+ * vlan_id is a 12 bit number.
+ * The VFTA array is actually a 4096 bit array, 128 of 32bit elements.
+ * 2^5 = 32. The val of lower 5 bits specifies the bit in the 32bit element.
+ * The higher 7 bit val specifies VFTA array index.
+ */
+#define I40E_VFTA_BIT(vlan_id)(1 << ((vlan_id) & 0x1F))
+#define I40E_VFTA_IDX(vlan_id)((vlan_id) >> 5)
+
 /* Default TC traffic in case DCB is not enabled */
 #define I40E_DEFAULT_TCMAP0x1
 #define I40E_FDIR_QUEUE_ID0
-- 
1.8.1.4

[dpdk-dev] [PATCH v4 1/2] lib/librte_pmd_i40e: set vlan id filter fix

[Huawei Xie]

">> 5" rather than ">> 4"

vlan id is a 12 bit value.
VFTA is 128 x 32 bit array (128 double word array) which could store 2^12 vlan 
bits.
Each bit represents whether corresponding vlan tag is set in the VSI.
Use high 7 bits as the index for the double word array.

Signed-off-by: Huawei Xie 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index dacf2db..518597f 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -4172,14 +4172,11 @@ i40e_set_vlan_filter(struct i40e_vsi *vsi,
 {
uint32_t vid_idx, vid_bit;

-#define UINT32_BIT_MASK  0x1F
-#define VALID_VLAN_BIT_MASK  0xFFF
/* VFTA is 32-bits size array, each element contains 32 vlan bits, Find 
the
 *  element first, then find the bits it belongs to
 */
-   vid_idx = (uint32_t) ((vlan_id & VALID_VLAN_BIT_MASK) >>
- sizeof(uint32_t));
-   vid_bit = (uint32_t) (1 << (vlan_id & UINT32_BIT_MASK));
+   vid_idx = (uint32_t) ((vlan_id >> 5) & 0x7F);
+   vid_bit = (uint32_t) (1 << (vlan_id & 0x1F));

if (on)
vsi->vfta[vid_idx] |= vid_bit;
-- 
1.8.1.4

[dpdk-dev] [PATCH v4 0/2] lib/librte_pmd_i40e: set vlan filter fix

[Huawei Xie]

This patchset fixes "set vlan filter" issue.

v2 changes:
* add two macros I40E_VFTA_IDX and I40E_VFTA_BIT for VFTA array operation.

v3 changes:
* code style fix
* rebase on latest commit

v4 changes:
* add more descriptive commit message

Huawei Xie (2):
  vlan id set fix
  add I40E_VFTA_IDX and I40E_VFTA_BIT macros for VFTA related operation

 lib/librte_pmd_i40e/i40e_ethdev.c | 20 ++--
 lib/librte_pmd_i40e/i40e_ethdev.h |  9 +
 2 files changed, 19 insertions(+), 10 deletions(-)

-- 
1.8.1.4

[dpdk-dev] endianness with ICC

[Thomas Monjalon]

I'm looking at endian detection to make it work with several compilers.

During this global check, I've seen some code specific to ICC:
http://dpdk.org/browse/dpdk/tree/app/test-pmd/testpmd.h#n562
If it's still really useful, it should in rte_byteorder.h, not in testpmd.

But, if possible, I'd prefer to remove this workaround.

Any opinion?

-- 
Thomas

[dpdk-dev] [PATCH 2/2] doc: Updated image files for rte_mbuf changes in 1.8

[Bruce Richardson]

The two image files showing the structure of the rte_mbuf data
structure required some minor updates to take account of the changes
introduced to the structure in the 1.8 release

Signed-off-by: Bruce Richardson 
---
 doc/guides/prog_guide/img/mbuf1.svg | 44 +---
 doc/guides/prog_guide/img/mbuf2.svg | 57 ++---
 2 files changed, 47 insertions(+), 54 deletions(-)

diff --git a/doc/guides/prog_guide/img/mbuf1.svg 
b/doc/guides/prog_guide/img/mbuf1.svg
index 0b8ff00..3d6beae 100644
--- a/doc/guides/prog_guide/img/mbuf1.svg
+++ b/doc/guides/prog_guide/img/mbuf1.svg
@@ -48,7 +48,7 @@
height="288.34286"
id="svg3868"
version="1.1"
-   inkscape:version="0.48.4 r9939"
+   inkscape:version="0.48.5 r10040"
sodipodi:docname="mbuf1.svg"
sodipodi:version="0.32"
inkscape:output_extension="org.inkscape.output.svg.inkscape">
@@ -328,16 +328,16 @@
  inkscape:pageopacity="0.0"
  inkscape:pageshadow="2"
  inkscape:zoom="2.8"
- inkscape:cx="424.95386"
+ inkscape:cx="344.29455"
  inkscape:cy="143.63151"
  inkscape:document-units="px"
  inkscape:current-layer="layer1"
  showgrid="false"
- inkscape:window-width="1650"
- inkscape:window-height="1059"
- inkscape:window-x="177"
- inkscape:window-y="111"
- inkscape:window-maximized="0"
+ inkscape:window-width="1920"
+ inkscape:window-height="1017"
+ inkscape:window-x="1592"
+ inkscape:window-y="285"
+ inkscape:window-maximized="1"
  fit-margin-top="0.1"
  fit-margin-left="0.1"
  fit-margin-right="0.1"
@@ -416,17 +416,17 @@
 rte_mbuf (type is pkt)
+ style="font-weight:bold">struct rte_mbuf 
 rte_pktmbuf_mtod(m)or m->pkt.data
+ y="119.50503"
+ id="tspan5223">rte_pktmbuf_mtod(m)
 m->pkt.next = NULL
+ x="83.928574"
+ y="284.14789">m->pkt.next = NULL
 tailroom
 multi-segmented rte_mbuf (type is 
pkt)
+ style="font-weight:bold">multi-segmented rte_mbuf
 rte_pktmbuf_mtod(m)or m->pkt.data
+ x="78.793297"
+ y="498.27075"
+ id="tspan5223-9">rte_pktmbuf_mtod(m)
 rte_pktmbuf_pktlen(m) = rte_pktmbuf_datalen(m) 
+rte_pktmbuf_datalen(mseg2) + 
rte_pktmbuf_datalen(mseg3)
+ x="233.53358"
+ y="483.38562"
+ id="tspan6985">rte_pktmbuf_datalen(mseg2) + 
rte_pktmbuf_datalen(mseg3)
 

[dpdk-dev] [PATCH 1/2] doc: update mbuf section of programmer's guide for 1.8

[Bruce Richardson]

In Release 1.8, the mbuf structure was significantly reworked to add
extra information, leading to the structure being split across two
cache lines, and the data pointer being replaced by an offset. The
description of the library in the programmer's guide document needs
to be updated to take account of these changes.

Signed-off-by: Bruce Richardson 
---
 doc/guides/prog_guide/mbuf_lib.rst | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/doc/guides/prog_guide/mbuf_lib.rst 
b/doc/guides/prog_guide/mbuf_lib.rst
index 4e1ccf0..d6b6e50 100644
--- a/doc/guides/prog_guide/mbuf_lib.rst
+++ b/doc/guides/prog_guide/mbuf_lib.rst
@@ -37,10 +37,12 @@ The mbuf library provides the ability to allocate and free 
buffers (mbufs)
 that may be used by the Intel? DPDK application to store message buffers.
 The message buffers are stored in a mempool, using the :ref:`Mempool Library 
`.

-A rte_mbuf struct can carry network packet buffers (type is RTE_MBUF_PKT)
-or generic control buffers (type is RTE_MBUF_CTRL).
+A rte_mbuf struct can carry network packet buffers
+or generic control buffers (indicated by the CTRL_MBUF_FLAG).
 This can be extended to other types.
-The rte_mbuf is kept as small as possible (one cache line if possible).
+The rte_mbuf header structure is kept as small as possible and currently uses
+just two cache lines, with the most frequently used fields being on the first
+of the two cache lines.

 Design of Packet Buffers
 
@@ -57,17 +59,17 @@ the complete separation of the allocation of metadata 
structures from the alloca

 The first method was chosen for the Intel? DPDK.
 The metadata contains control information such as message type, length,
-pointer to the start of the data and a pointer for additional mbuf structures 
allowing buffer chaining.
+offset to the start of the data and a pointer for additional mbuf structures 
allowing buffer chaining.

 Message buffers that are used to carry network packets can handle buffer 
chaining
 where multiple buffers are required to hold the complete packet.
-This is the case for jumbo frames that are composed of many mbufs linked 
together through their pkt.next field.
+This is the case for jumbo frames that are composed of many mbufs linked 
together through their next field.

 For a newly allocated mbuf, the area at which the data begins in the message 
buffer is
 RTE_PKTMBUF_HEADROOM bytes after the beginning of the buffer, which is cache 
aligned.
 Message buffers may be used to carry control information, packets, events,
 and so on between different entities in the system.
-Message buffers may also use their data pointers to point to other message 
buffer data sections or other structures.
+Message buffers may also use their buffer pointers to point to other message 
buffer data sections or other structures.

 Figure 8 and Figure 9 show some of these scenarios.

@@ -109,9 +111,8 @@ Allocating and Freeing mbufs
 

 Allocating a new mbuf requires the user to specify the mempool from which the 
mbuf should be taken.
-For a packet mbuf, it contains one segment, with a length of 0.
-The pointer to data is initialized to have some bytes of headroom in the 
buffer (RTE_PKTMBUF_HEADROOM).
-For a control mbuf, it is initialized with data pointing to the beginning of 
the buffer and a length of zero.
+For any newly-allocated mbuf, it contains one segment, with a length of 0.
+The offset to data is initialized to have some bytes of headroom in the buffer 
(RTE_PKTMBUF_HEADROOM).

 Freeing a mbuf means returning it into its original mempool.
 The content of an mbuf is not modified when it is stored in a pool (as a free 
mbuf).
@@ -151,7 +152,8 @@ Direct and Indirect Buffers
 ---

 A direct buffer is a buffer that is completely separate and self-contained.
-An indirect buffer behaves like a direct buffer but for the fact that the data 
pointer it contains points to data in another direct buffer.
+An indirect buffer behaves like a direct buffer but for the fact that the 
buffer pointer and
+data offset in it refer to data in another direct buffer.
 This is useful in situations where packets need to be duplicated or fragmented,
 since indirect buffers provide the means to reuse the same packet data across 
multiple buffers.

-- 
2.1.1

[dpdk-dev] [PATCH 0/2] Update programmers guide doc, mbuf chapter

[Bruce Richardson]

These patches contain updates to the programmers guide document to keep it in
sync with the code changes made to the rte_mbuf data structure.

Bruce Richardson (2):
  doc: update mbuf section of programmer's guide for 1.8
  doc: Updated image files for rte_mbuf changes in 1.8

 doc/guides/prog_guide/img/mbuf1.svg | 44 +---
 doc/guides/prog_guide/img/mbuf2.svg | 57 ++---
 doc/guides/prog_guide/mbuf_lib.rst  | 22 +++---
 3 files changed, 59 insertions(+), 64 deletions(-)

-- 
2.1.1

[dpdk-dev] [PATCH] Doc: Adding Distributor Sample Application to Sample App UG

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Tuesday, December 2, 2014 2:03 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] Doc: Adding Distributor Sample Application to 
> Sample App UG
> 
> New distributor sample app user guide section for sample app ug.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH] enic: fix warnings

[Thomas Monjalon]

A lot of warnings were not seen because $(WERROR_FLAGS) was not set
in the Makefile. But they appear with toolchains that enforce more checks.

-Wno-deprecated seems useless.
-Wno-strict-aliasing is added to avoid false positives.

This patch cleans up unused variable, unused functions, wrong types,
static declarations, etc. A lot of functions have unused parameters;
it suggests that more clean-up could be needed.

Signed-off-by: Thomas Monjalon 
---
 lib/librte_pmd_enic/Makefile |  3 +-
 lib/librte_pmd_enic/enic.h   |  4 +-
 lib/librte_pmd_enic/enic_ethdev.c| 20 -
 lib/librte_pmd_enic/enic_main.c  | 81 +++-
 lib/librte_pmd_enic/vnic/vnic_cq.h   |  1 -
 lib/librte_pmd_enic/vnic/vnic_dev.c  | 22 +++---
 lib/librte_pmd_enic/vnic/vnic_dev.h  |  4 +-
 lib/librte_pmd_enic/vnic/vnic_intr.c |  5 ---
 8 files changed, 46 insertions(+), 94 deletions(-)

diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile
index 948ec96..a2a623f 100644
--- a/lib/librte_pmd_enic/Makefile
+++ b/lib/librte_pmd_enic/Makefile
@@ -39,7 +39,8 @@ LIB = librte_pmd_enic.a

 CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/vnic/
 CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/
-CFLAGS += -O3 -Wno-deprecated
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS) -Wno-strict-aliasing

 VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src

diff --git a/lib/librte_pmd_enic/enic.h b/lib/librte_pmd_enic/enic.h
index f128e64..c43417c 100644
--- a/lib/librte_pmd_enic/enic.h
+++ b/lib/librte_pmd_enic/enic.h
@@ -134,7 +134,7 @@ struct enic {
unsigned int intr_count;
 };

-static inline unsigned int enic_cq_rq(struct enic *enic, unsigned int rq)
+static inline unsigned int enic_cq_rq(__rte_unused struct enic *enic, unsigned 
int rq)
 {
return rq;
 }
@@ -144,7 +144,7 @@ static inline unsigned int enic_cq_wq(struct enic *enic, 
unsigned int wq)
return enic->rq_count + wq;
 }

-static inline unsigned int enic_msix_err_intr(struct enic *enic)
+static inline unsigned int enic_msix_err_intr(__rte_unused struct enic *enic)
 {
return 0;
 }
diff --git a/lib/librte_pmd_enic/enic_ethdev.c 
b/lib/librte_pmd_enic/enic_ethdev.c
index f582152..9cb 100644
--- a/lib/librte_pmd_enic/enic_ethdev.c
+++ b/lib/librte_pmd_enic/enic_ethdev.c
@@ -67,7 +67,7 @@ RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, 
PCI_DEVICE_ID_CISCO_VIC_ENET_VF)

 static int enicpmd_fdir_remove_perfect_filter(struct rte_eth_dev *eth_dev,
struct rte_fdir_filter *fdir_filter,
-   uint16_t soft_id)
+   __rte_unused uint16_t soft_id)
 {
struct enic *enic = pmd_priv(eth_dev);

@@ -76,7 +76,7 @@ static int enicpmd_fdir_remove_perfect_filter(struct 
rte_eth_dev *eth_dev,
 }

 static int enicpmd_fdir_add_perfect_filter(struct rte_eth_dev *eth_dev,
-   struct rte_fdir_filter *fdir_filter, uint16_t soft_id,
+   struct rte_fdir_filter *fdir_filter, __rte_unused uint16_t soft_id,
uint8_t queue, uint8_t drop)
 {
struct enic *enic = pmd_priv(eth_dev);
@@ -103,7 +103,7 @@ static void enicpmd_dev_tx_queue_release(void *txq)
 static int enicpmd_dev_setup_intr(struct enic *enic)
 {
int ret;
-   int index;
+   unsigned int index;

ENICPMD_FUNC_TRACE();

@@ -134,7 +134,7 @@ static int enicpmd_dev_tx_queue_setup(struct rte_eth_dev 
*eth_dev,
uint16_t queue_idx,
uint16_t nb_desc,
unsigned int socket_id,
-   const struct rte_eth_txconf *tx_conf)
+   __rte_unused const struct rte_eth_txconf *tx_conf)
 {
int ret;
struct enic *enic = pmd_priv(eth_dev);
@@ -215,7 +215,7 @@ static int enicpmd_dev_rx_queue_setup(struct rte_eth_dev 
*eth_dev,
uint16_t queue_idx,
uint16_t nb_desc,
unsigned int socket_id,
-   const struct rte_eth_rxconf *rx_conf,
+   __rte_unused const struct rte_eth_rxconf *rx_conf,
struct rte_mempool *mp)
 {
int ret;
@@ -334,7 +334,7 @@ static void enicpmd_dev_close(struct rte_eth_dev *eth_dev)
 }

 static int enicpmd_dev_link_update(struct rte_eth_dev *eth_dev,
-   int wait_to_complete)
+   __rte_unused int wait_to_complete)
 {
struct enic *enic = pmd_priv(eth_dev);
int ret;
@@ -428,7 +428,7 @@ static void enicpmd_dev_allmulticast_disable(struct 
rte_eth_dev *eth_dev)

 static void enicpmd_add_mac_addr(struct rte_eth_dev *eth_dev,
struct ether_addr *mac_addr,
-   uint32_t index, uint32_t pool)
+   __rte_unused uint32_t index, __rte_unused uint32_t pool)
 {
struct enic *enic = pmd_priv(eth_dev);

@@ -436,7 +436,7 @@ static void enicpmd_add_mac_addr(struct rte_eth_dev 
*eth_dev,
enic_set_mac_address(enic, mac_addr->addr_bytes);
 }

-static void enicpmd_remove_mac_addr(struct rte_eth_dev *eth_dev, uint32_t 
index)
+static void enicpmd_remove_mac_addr(struct rte_eth_dev *eth_dev, __rte_unused 
uint32_t index)
 {
struct enic *enic = pmd_priv(eth_dev);

@@ -457,7 +457,6 @@ stati

[dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

[didier.pallard]

Hello,

On 12/02/2014 07:52 AM, Jijiang Liu wrote:
> Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and 
> outer_l3_len field, and rework csum forward engine and i40e PMD due to  these 
> changes.
>
> Signed-off-by: Jijiang Liu 
[...]
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -276,8 +276,8 @@ struct rte_mbuf {
>   uint64_t tso_segsz:16; /**< TCP TSO segment size */
>   
>   /* fields for TX offloading of tunnels */
> - uint64_t inner_l3_len:9; /**< inner L3 (IP) Hdr Length. 
> */
> - uint64_t inner_l2_len:7; /**< inner L2 (MAC) Hdr 
> Length. */
> + uint64_t outer_l3_len:9; /**< Outer L3 (IP) Hdr Length. 
> */
> + uint64_t outer_l2_len:7; /**< Outer L2 (MAC) Hdr 
> Length. */
>   
>   /* uint64_t unused:8; */
>   };

Sorry for entering lately this discussion, but i'm not convinced by the 
choice of outer_lx_len rather than inner_lx_len for new fields.
I agree with Olivier that new flags should only be related to the use of 
new fields, to maintain coherency with oldest implementations.
But from a stack point of view, i think it is better to have lx_len 
fields that target the outer layers, and to name new fields inner_lx_len.

Let's discuss the two possibilities.

1) outer_lx_len fields are introduced.
In this case, the stack should have knowledge that it is processing 
tunneled packets to use outer_lx_len rather than lx_len,
or stack should always use outer_lx_len packet and move those fields to 
lx_len packets if no tunneling occurs...
I think it will induce extra processing that does not seem to be really 
needed.

2) inner_lx_len fields are introduced.
In this case, the stack first uses lx_len fields. When packet should be 
tunneled, lx_len fields are moved to inner_lx_len fields.
Then the stack can process the outer layer and still use the lx_len fields.

For  example:
an eth/IP/TCP forged packet will look like this:

Ether/IP/UDP/xxx
   m->flags = IP_CKSUM
   m->l2_len = sizeof(ether)
   m->l3_len = sizeof(ip)
   m->l4_len = sizeof(udp)
   m->inner_l2_len = 0
   m->inner_l3_len = 0

When entering tunnel for example a VXLAN interface, lx_len will be moved 
to inner_lx_len

Ether/IP/UDP/xxx
   m->flags = INNER_IP_CKSUM
   m->l2_len = 0
   m->l3_len = 0
   m->l4_len = 0
   m->inner_l2_len = sizeof(ether)
   m->inner_l3_len = sizeof(ip)


once complete encapsulation is processed by the stack, the packet will 
look like

Ether/IP/UDP/VXLAN/Ether/IP/UDP/xxx
   m->flags = IP_CKSUM | INNER_IP_CKSUM
   m->l2_len = sizeof(ether)
   m->l3_len = sizeof(ip)
   m->l4_len = sizeof(udp)
   m->inner_l2_len = sizeof(ether) + sizeof (vxlan)
   m->inner_l3_len = sizeof(ip)


didier

[dpdk-dev] Regarding KNI issue

[Venkateswara Rao Dokku]

HI,

Our goal is to run traffic b/w KVM guest to linux via kni_vhost. The
topology is given below

Physical port eth1 is bound to DPDK using tools/setup.sh.
We did loaded Igb_uio module, allocated hugepages etc.

  *DPDK port 0*
^
 |
 |
 ---
 *Physical port(eth1)*~~* vEth0*
  |
  |
  |
  *eth10(different machine connected back-to-back)*


We loaded KNI module and ran the KNI applicaiton with the following command
*kni -c 0xff -n 4 -- -p 0x1 -P --config="(0,4,6)"*
and we could see vEth0 added in kernel.

1. Now, How can we test traffic with the KNI interface to external world. ??
We were not able to ping between *vEth0* and *eth10*.
2. We launched a KVM guest machine, and provided *vEth0* as the tap
interface. When we initiated ping to *eth10* from the guest, we can see the
arp requests on* vEth0 (saw in tcpdump)*. But these packets are not
reaching *eth10. *  If we ping from *eth10*, we dont see any packets on
*vEth0*.

Do we need to do any other configuration other than this?
Any help is much appreciated.

-- 
Thanks & Regards,
Venkateswara Rao Dokku

[dpdk-dev] [PATCH v5 0/3] i40e VXLAN TX checksum rework

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Tuesday, December 02, 2014 3:06 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v5 0/3] i40e VXLAN TX checksum rework
> 
> We have got some feedback about backward compatibility of VXLAN TX checksum 
> offload API with 1G/10G NIC after the i40e VXLAN
> TX checksum codes were applied, so we have to rework the APIs on i40e, 
> including the changes of mbuf, i40e PMD and csum forward
> engine.
> 
> The main changes in mbuf are as follows, in place of removing 
> PKT_TX_VXLAN_CKSUM, we introduce 4 new flags:
> PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV6 and 
> PKT_TX_UDP_TUNNEL_PKT. Replace the inner_l2_len
> and the inner_l3_len field with the outer_l2_len and outer_l3_len field.
> 
> Let's use a few examples to demonstrate how to use these new flags and 
> existing flags in rte_mbuf.h
> Let say we have a tunnel packet: 
> eth_hdr_out/ipv4_hdr_out/udp_hdr_out/vxlan_hdr/ehtr_hdr_in/ipv4_hdr_in/tcp_hdr_in.
>  There
> could be several scenarios:
> 
> A) User requests HW offload for ipv4_hdr_out checksum.
> He doesn't care is it a tunnelled packet or not. So he sets:
> 
> mb->l2_len = eth_hdr_out;
> mb->l3_len = ipv4_hdr_out;
> mb->ol_flags |= PKT_TX_IPV4_CSUM;
> 
> B) User is aware that it is a tunnelled packet and requests HW offload for 
> ipv4_hdr_in and tcp_hdr_in *only*.
> He doesn't care about outer IP checksum offload. In that case, for FVL  he 
> has 2 choices:
>1. Treat that packet as a 'proper' tunnelled packet, and fill all the 
> fields:
>  mb->l2_len = udp_hdr_out + vxlan_hdr +eth_hdr_in;
>  mb->l3_len = ipv4_hdr_in;
>  mb->outer_l2_len = eth_hdr_out;
>  mb->outer_l3_len = ipv4_hdr_out;
>  mb->ol_flags |= PKT_TX_UDP_TUNNEL_PKT | PKT_TX_IP_CKSUM |  
> PKT_TX_TCP_CKSUM;
> 
>2. As user doesn't care about outer IP hdr checksum, he can treat 
> everything before ipv4_hdr_in as L2 header.
>So he knows, that it is a tunnelled packet, but makes HW to treat it as 
> ordinary (non-tunnelled) packet:
>  mb->l2_len = eth_hdr_out + ipv4_hdr_out + udp_hdr_out + vxlan_hdr + 
> ehtr_hdr_in;
>  mb->l3_len = ipv4_hdr_in;
>  mb->ol_flags |= PKT_TX_IP_CKSUM |  PKT_TX_TCP_CKSUM;
> 
> i40e PMD will support both B.1 and B.2, but ixgbe/igb/em PMD supports only 
> B.2.
> if HW supports both - it will be up to user app which method to choose.
> tespmd will support both methods, and it should be configurable by user which 
> approach to use (cmdline parameter).
> So the user can try/test both methods and select an appropriate for him.
> 
> C) User knows that is a tunnelled packet, and wants HW offload for all 3 
> checksums:  outer IP hdr checksum, inner IP checksum, inner
> TCP checksum.
> Then he has to setup all TX checksum fields:
>  mb->l2_len =  udp_hdr_out + vxlan_hdr +eth_hdr_in;;
>  mb->l3_len = ipv4_hdr_in;
>  mb->outer_l2_len = eth_hdr_out;
>  mb->outer_l3_len = ipv4_hdr_out;
>  mb->ol_flags |= PKT_TX_OUT_IP_CKSUM  | PKT_TX_UDP_TUNNEL_PKT | 
> PKT_TX_IP_CKSUM |  PKT_TX_TCP_CKSUM;
> 
> Change notes:
> v2 changes:
>  remove PKT_TX_IP_CKSUM alias.
>  add PKT_TX_OUT_IP_CKSUM and PKT_TX_OUTER_IPV6 in rte_get_tx_ol_flag_name.
>  spliting mbuf changes into two patches.
>  fix MACLEN caculation issue in i40e driver
>  fix some issues in csumonly.c
>  change cover letter.
> v3 changes:
>  fix MACLEN caculation issue in i40e driver when non-tunneling packet
> v4 changes:
>  reorganize patches to avoid compilation to be broken between patches.
>  remove l4_tun_len from mbuf structure.
>  add PKT_TX_OUTER_IPV4 to indicate no IP checksum offload requirement for 
> tunneling packet.
>  change i40e PMD and csum engine due to above changes.
> 
> v5 changes:
>  according to Konstantin's comments, optimize process_outer_cksums() in 
> order to avoid setting PKT_TX_OUTER_IPV4 flags for the
> case when user didn't enable TESTPMD_TX_OFFLOAD_VXLAN_CKSUM
> 
> Jijiang Liu (3):
>   Redefine PKT_TX_IPV4, PKT_TX_IPV6 and PKT_TX_VLAN_PKT;
>   Replace PKT_TX_VXLAN_CKSUM with PKT_TX_UDP_TUNNEL_PKT, and add 3 TX flags, 
> which are PKT_TX_OUTER_IP_CKSUM,
> PKT_TX_OUTER_IPV4 and PKT_TX_OUTER_IPV6,and rework csum forward engine and 
> i40e pmd due to these changes;
>   Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len 
> and outer_l3_len field, and rework csum forward engine
> and i40e pmd due to  these changes;
> 
>  app/test-pmd/csumonly.c |   69 ++
>  lib/librte_mbuf/rte_mbuf.c  |7 +++-
>  lib/librte_mbuf/rte_mbuf.h  |   25 +
>  lib/librte_pmd_i40e/i40e_rxtx.c |   44 +
>  4 files changed, 86 insertions(+), 59 deletions(-)
> 
> --
> 1.7.7.6

Acked-by: Konstantin Ananyev 

[dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

[Ananyev, Konstantin]

Hi Didier

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of didier.pallard
> Sent: Tuesday, December 02, 2014 2:53 PM
> To: Liu, Jijiang; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the 
> inner_l3_len fields
> 
> Hello,
> 
> On 12/02/2014 07:52 AM, Jijiang Liu wrote:
> > Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len 
> > and outer_l3_len field, and rework csum forward engine
> and i40e PMD due to  these changes.
> >
> > Signed-off-by: Jijiang Liu 
> [...]
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -276,8 +276,8 @@ struct rte_mbuf {
> > uint64_t tso_segsz:16; /**< TCP TSO segment size */
> >
> > /* fields for TX offloading of tunnels */
> > -   uint64_t inner_l3_len:9; /**< inner L3 (IP) Hdr Length. 
> > */
> > -   uint64_t inner_l2_len:7; /**< inner L2 (MAC) Hdr 
> > Length. */
> > +   uint64_t outer_l3_len:9; /**< Outer L3 (IP) Hdr Length. 
> > */
> > +   uint64_t outer_l2_len:7; /**< Outer L2 (MAC) Hdr 
> > Length. */
> >
> > /* uint64_t unused:8; */
> > };
> 
> Sorry for entering lately this discussion, but i'm not convinced by the
> choice of outer_lx_len rather than inner_lx_len for new fields.
> I agree with Olivier that new flags should only be related to the use of
> new fields, to maintain coherency with oldest implementations.
> But from a stack point of view, i think it is better to have lx_len
> fields that target the outer layers, and to name new fields inner_lx_len.
> 
> Let's discuss the two possibilities.
> 
> 1) outer_lx_len fields are introduced.
> In this case, the stack should have knowledge that it is processing
> tunneled packets to use outer_lx_len rather than lx_len,
> or stack should always use outer_lx_len packet and move those fields to
> lx_len packets if no tunneling occurs...
> I think it will induce extra processing that does not seem to be really
> needed.
> 
> 2) inner_lx_len fields are introduced.
> In this case, the stack first uses lx_len fields. When packet should be
> tunneled, lx_len fields are moved to inner_lx_len fields.
> Then the stack can process the outer layer and still use the lx_len fields.

Not sure, that I understood why 2) is better than 1).
Let say,  you have a 'normal' (non-tunnelling) packet: ether/IP/TCP
In that case you still use mbuf's l2_len/l3_len/l4_len fields and setup 
ol_flags as usual.
Then later, you decided to 'tunnel' that packet.
So you just fill mbuf's outer_l2_len/outer_l3_len, setup TX_OUTER_* and 
TX_TUNNEL_* bits in ol_flags and probably update l2_len.
l3_len/l4_len and ol_flags bits set for them remain intact.
That's with 1)

With 2) - you'll have to move l3_len/l4_len to inner_lx_len. 
And I suppose ol_flags values too:
ol_flags &= ~PKT_ IP_CKSUM;
ol_flgas  |=  PKT_INNER_IP_CKSUM
?
And same for L4_CKSUM flags too?

Konstantin

> 
> For  example:
> an eth/IP/TCP forged packet will look like this:
> 
> Ether/IP/UDP/xxx
>m->flags = IP_CKSUM
>m->l2_len = sizeof(ether)
>m->l3_len = sizeof(ip)
>m->l4_len = sizeof(udp)
>m->inner_l2_len = 0
>m->inner_l3_len = 0
> 
> When entering tunnel for example a VXLAN interface, lx_len will be moved
> to inner_lx_len
> 
> Ether/IP/UDP/xxx
>m->flags = INNER_IP_CKSUM
>m->l2_len = 0
>m->l3_len = 0
>m->l4_len = 0
>m->inner_l2_len = sizeof(ether)
>m->inner_l3_len = sizeof(ip)
> 
> 
> once complete encapsulation is processed by the stack, the packet will
> look like
> 
> Ether/IP/UDP/VXLAN/Ether/IP/UDP/xxx
>m->flags = IP_CKSUM | INNER_IP_CKSUM
>m->l2_len = sizeof(ether)
>m->l3_len = sizeof(ip)
>m->l4_len = sizeof(udp)
>m->inner_l2_len = sizeof(ether) + sizeof (vxlan)
>m->inner_l3_len = sizeof(ip)
> 
> 
> didier
> 

[dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields

[Jijiang Liu]

Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and 
outer_l3_len field, and rework csum forward engine and i40e PMD due to  these 
changes.

Signed-off-by: Jijiang Liu 
---
 app/test-pmd/csumonly.c |   60 +-
 lib/librte_mbuf/rte_mbuf.h  |4 +-
 lib/librte_pmd_i40e/i40e_rxtx.c |   38 +---
 3 files changed, 55 insertions(+), 47 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 9094967..e874ac5 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -189,11 +189,12 @@ process_inner_cksums(void *l3_hdr, uint16_t ethertype, 
uint16_t l3_len,
} else {
if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM)
ol_flags |= PKT_TX_IP_CKSUM;
-   else
+   else {
ipv4_hdr->hdr_checksum =
rte_ipv4_cksum(ipv4_hdr);
+   ol_flags |= PKT_TX_IPV4;
+   }
}
-   ol_flags |= PKT_TX_IPV4;
} else if (ethertype == _htons(ETHER_TYPE_IPv6))
ol_flags |= PKT_TX_IPV6;
else
@@ -262,22 +263,25 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
outer_ethertype,
if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) {
ipv4_hdr->hdr_checksum = 0;

-   if ((testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) == 0)
+   if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
+   ol_flags |= PKT_TX_OUTER_IP_CKSUM;
+   else {
+   ol_flags |= PKT_TX_OUTER_IPV4;
ipv4_hdr->hdr_checksum = rte_ipv4_cksum(ipv4_hdr);
-   }
+   }
+   } else
+   ol_flags |= PKT_TX_OUTER_IPV6;

udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + outer_l3_len);
/* do not recalculate udp cksum if it was 0 */
if (udp_hdr->dgram_cksum != 0) {
udp_hdr->dgram_cksum = 0;
-   if ((testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM) == 0) {
-   if (outer_ethertype == _htons(ETHER_TYPE_IPv4))
-   udp_hdr->dgram_cksum =
-   rte_ipv4_udptcp_cksum(ipv4_hdr, 
udp_hdr);
-   else
-   udp_hdr->dgram_cksum =
-   rte_ipv6_udptcp_cksum(ipv6_hdr, 
udp_hdr);
-   }
+   if (outer_ethertype == _htons(ETHER_TYPE_IPv4))
+   udp_hdr->dgram_cksum =
+   rte_ipv4_udptcp_cksum(ipv4_hdr, udp_hdr);
+   else
+   udp_hdr->dgram_cksum =
+   rte_ipv6_udptcp_cksum(ipv6_hdr, udp_hdr);
}

return ol_flags;
@@ -303,8 +307,7 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
outer_ethertype,
  * TESTPMD_TX_OFFLOAD_* in ports[tx_port].tx_ol_flags. They control
  * wether a checksum must be calculated in software or in hardware. The
  * IP, UDP, TCP and SCTP flags always concern the inner layer.  The
- * VxLAN flag concerns the outer IP and UDP layer (if packet is
- * recognized as a vxlan packet).
+ * VxLAN flag concerns the outer IP(if packet is recognized as a vxlan packet).
  */
 static void
 pkt_burst_checksum_forward(struct fwd_stream *fs)
@@ -320,7 +323,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
uint16_t i;
uint64_t ol_flags;
uint16_t testpmd_ol_flags;
-   uint8_t l4_proto;
+   uint8_t l4_proto, l4_tun_len = 0;
uint16_t ethertype = 0, outer_ethertype = 0;
uint16_t l2_len = 0, l3_len = 0, l4_len = 0;
uint16_t outer_l2_len = 0, outer_l3_len = 0;
@@ -360,6 +363,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)

ol_flags = 0;
tunnel = 0;
+   l4_tun_len = 0;
m = pkts_burst[i];

/* Update the L3/L4 checksum error packet statistics */
@@ -378,14 +382,16 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
if (l4_proto == IPPROTO_UDP) {
udp_hdr = (struct udp_hdr *)((char *)l3_hdr + l3_len);

+   /* check udp destination port, 4789 is the default
+* vxlan port (rfc7348) */
+   if (udp_hdr->dst_port == _htons(4789)) {
+   l4_tun_len = ETHER_VXLAN_HLEN;
+   tunnel = 1;
+
/* currently, this flag is set by i40e only if the
 * packet is vxlan */
-   if (((m->ol_flags & PKT_RX_TUNNEL_IPV4_HDR) ||
-   (m->ol_flags & PKT_RX_TUNNEL_IPV6_HDR)))
-   tunnel = 1;
-   

[dpdk-dev] [PATCH v4 2/3] mbuf:add three TX ol_flags and repalce PKT_TX_VXLAN_CKSUM

[Jijiang Liu]

Replace PKT_TX_VXLAN_CKSUM with PKT_TX_UDP_TUNNEL_PKT in order to indicate a 
packet is an UDP tunneling packet, and introduce 3 TX offload flags for outer 
IP TX checksum, which are PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV4 and 
PKT_TX_OUTER_IPV6 respectively;Rework csum forward engine and i40e PMD due to 
these changes.

Signed-off-by: Jijiang Liu 
---
 app/test-pmd/csumonly.c |9 +++--
 lib/librte_mbuf/rte_mbuf.c  |7 ++-
 lib/librte_mbuf/rte_mbuf.h  |   11 ++-
 lib/librte_pmd_i40e/i40e_rxtx.c |6 +++---
 4 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index d8c080a..9094967 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -257,7 +257,7 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
outer_ethertype,
uint64_t ol_flags = 0;

if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
-   ol_flags |= PKT_TX_VXLAN_CKSUM;
+   ol_flags |= PKT_TX_UDP_TUNNEL_PKT;

if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) {
ipv4_hdr->hdr_checksum = 0;
@@ -470,7 +470,12 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
{ PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK },
{ PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK },
{ PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK },
-   { PKT_TX_VXLAN_CKSUM, PKT_TX_VXLAN_CKSUM },
+   { PKT_TX_UDP_TUNNEL_PKT, PKT_TX_UDP_TUNNEL_PKT 
},
+   { PKT_TX_IPV4, PKT_TX_IPV4 },
+   { PKT_TX_IPV6, PKT_TX_IPV6 },
+   { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM 
},
+   { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4 },
+   { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6 },
{ PKT_TX_TCP_SEG, PKT_TX_TCP_SEG },
};
unsigned j;
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 87c2963..1b14e02 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -240,8 +240,13 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
case PKT_TX_SCTP_CKSUM: return "PKT_TX_SCTP_CKSUM";
case PKT_TX_UDP_CKSUM: return "PKT_TX_UDP_CKSUM";
case PKT_TX_IEEE1588_TMST: return "PKT_TX_IEEE1588_TMST";
-   case PKT_TX_VXLAN_CKSUM: return "PKT_TX_VXLAN_CKSUM";
+   case PKT_TX_UDP_TUNNEL_PKT: return "PKT_TX_UDP_TUNNEL_PKT";
case PKT_TX_TCP_SEG: return "PKT_TX_TCP_SEG";
+   case PKT_TX_IPV4: return "PKT_TX_IPV4";
+   case PKT_TX_IPV6: return "PKT_TX_IPV6";
+   case PKT_TX_OUTER_IP_CKSUM: return "PKT_TX_OUTER_IP_CKSUM";
+   case PKT_TX_OUTER_IPV4: return "PKT_TX_OUTER_IPV4";
+   case PKT_TX_OUTER_IPV6: return "PKT_TX_OUTER_IPV6";
default: return NULL;
}
 }
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index cbadf8e..6eb898f 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -118,7 +118,7 @@ extern "C" {
  */
 #define PKT_TX_TCP_SEG   (1ULL << 49)

-#define PKT_TX_VXLAN_CKSUM   (1ULL << 50) /**< TX checksum of VXLAN computed 
by NIC */
+#define PKT_TX_UDP_TUNNEL_PKT (1ULL << 50) /**< TX packet is an UDP tunneling 
packet */
 #define PKT_TX_IEEE1588_TMST (1ULL << 51) /**< TX IEEE1588 packet to 
timestamp. */

 /**
@@ -149,6 +149,15 @@ extern "C" {

 #define PKT_TX_VLAN_PKT  (1ULL << 57) /**< TX packet is a 802.1q VLAN 
packet. */

+/** Outer IP checksum of TX packet, computed by NIC for tunneling packet */
+#define PKT_TX_OUTER_IP_CKSUM   (1ULL << 58)
+
+/** Packet is outer IPv4 without requiring IP checksum offload for tunneling 
packet. */
+#define PKT_TX_OUTER_IPV4   (1ULL << 59)
+
+/** Tell the NIC it's an outer IPv6 packet for tunneling packet */
+#define PKT_TX_OUTER_IPV6(1ULL << 60)
+
 /* Use final bit of flags to indicate a control mbuf */
 #define CTRL_MBUF_FLAG   (1ULL << 63) /**< Mbuf contains control data */

diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 2d2ef04..078e973 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -478,7 +478,7 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
}

/* VXLAN packet TX checksum offload */
-   if (unlikely(ol_flags & PKT_TX_VXLAN_CKSUM)) {
+   if (unlikely(ol_flags & PKT_TX_UDP_TUNNEL_PKT)) {
uint8_t l4tun_len;

l4tun_len = ETHER_VXLAN_HLEN + inner_l2_len;
@@ -1158,8 +1158,8 @@ i40e_calc_context_desc(uint64_t flags)
 {
uint64_t mask = 0ULL;

-   if (flags | PKT_TX_VXLAN_CKSUM)
-   mask |= PKT_TX_VXLAN_CKSUM;
+   if (flags | PKT_TX_UDP_TUNNEL_PKT)
+   mask |= PKT_TX_UDP_TUNNEL_PKT;

 #ifdef RTE_LIBRTE_IEEE1588
mask |= PKT_TX_IEEE1588_TM

[dpdk-dev] [PATCH v4 1/3] mbuf:redefine three TX ol_flags

[Jijiang Liu]

The reason of redefining the PKT_TX_IPV4 and the PKT_TX_IPV6 is listed below,
It will avoid to send a packet with a bad info:
  - we receive a Ether/IP6/IP4/L4/data packet
  - the driver sets PKT_RX_IPV6_HDR
  - the stack decapsulates IP6
  - the stack sends the packet, it has the PKT_TX_IPV6 flag but it's an IPv4 
packet.

Signed-off-by: Jijiang Liu 
---
 lib/librte_mbuf/rte_mbuf.h |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 2e5fce5..cbadf8e 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -141,13 +141,13 @@ extern "C" {
 #define PKT_TX_IP_CKSUM  (1ULL << 54) /**< IP cksum of TX pkt. computed by 
NIC. */
 #define PKT_TX_IPV4_CSUM PKT_TX_IP_CKSUM /**< Alias of PKT_TX_IP_CKSUM. */

-/** Tell the NIC it's an IPv4 packet. Required for L4 checksum offload or TSO. 
*/
-#define PKT_TX_IPV4  PKT_RX_IPV4_HDR
+/** Packet is IPv4 without requiring IP checksum offload. */
+#define PKT_TX_IPV4  (1ULL << 55)

-/** Tell the NIC it's an IPv6 packet. Required for L4 checksum offload or TSO. 
*/
-#define PKT_TX_IPV6  PKT_RX_IPV6_HDR
+/** Tell the NIC it's an IPv6 packet.*/
+#define PKT_TX_IPV6  (1ULL << 56)

-#define PKT_TX_VLAN_PKT  (1ULL << 55) /**< TX packet is a 802.1q VLAN 
packet. */
+#define PKT_TX_VLAN_PKT  (1ULL << 57) /**< TX packet is a 802.1q VLAN 
packet. */

 /* Use final bit of flags to indicate a control mbuf */
 #define CTRL_MBUF_FLAG   (1ULL << 63) /**< Mbuf contains control data */
-- 
1.7.7.6

[dpdk-dev] [PATCH v4 0/3] i40e VXLAN TX checksum rework

[Jijiang Liu]

We have got some feedback about backward compatibility of VXLAN TX checksum 
offload API with 1G/10G NIC after the i40e VXLAN TX checksum codes were 
applied, so we have to rework the APIs on i40e, including the changes of mbuf, 
i40e PMD and csum forward engine.

The main changes in mbuf are as follows, in place of removing 
PKT_TX_VXLAN_CKSUM, we introduce 4 new flags: PKT_TX_OUTER_IP_CKSUM, 
PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV6 and PKT_TX_UDP_TUNNEL_PKT. Replace the 
inner_l2_len and the inner_l3_len field with the outer_l2_len and outer_l3_len 
field.

Let's use a few examples to demonstrate how to use these new flags and existing 
flags in rte_mbuf.h
Let say we have a tunnel packet: 
eth_hdr_out/ipv4_hdr_out/udp_hdr_out/vxlan_hdr/ehtr_hdr_in/ipv4_hdr_in/tcp_hdr_in.
 There could be several scenarios:

A) User requests HW offload for ipv4_hdr_out checksum.
He doesn't care is it a tunnelled packet or not. So he sets:

mb->l2_len = eth_hdr_out;
mb->l3_len = ipv4_hdr_out;
mb->ol_flags |= PKT_TX_IPV4_CSUM;

B) User is aware that it is a tunnelled packet and requests HW offload for 
ipv4_hdr_in and tcp_hdr_in *only*.
He doesn't care about outer IP checksum offload. In that case, for FVL  he has 
2 choices:
   1. Treat that packet as a 'proper' tunnelled packet, and fill all the fields:
 mb->l2_len = udp_hdr_out + vxlan_hdr +eth_hdr_in;
 mb->l3_len = ipv4_hdr_in;
 mb->outer_l2_len = eth_hdr_out;
 mb->outer_l3_len = ipv4_hdr_out;
 mb->ol_flags |= PKT_TX_UDP_TUNNEL_PKT | PKT_TX_IP_CKSUM |  
PKT_TX_TCP_CKSUM;

   2. As user doesn't care about outer IP hdr checksum, he can treat everything 
before ipv4_hdr_in as L2 header.
   So he knows, that it is a tunnelled packet, but makes HW to treat it as 
ordinary (non-tunnelled) packet:
 mb->l2_len = eth_hdr_out + ipv4_hdr_out + udp_hdr_out + vxlan_hdr + 
ehtr_hdr_in;
 mb->l3_len = ipv4_hdr_in;
 mb->ol_flags |= PKT_TX_IP_CKSUM |  PKT_TX_TCP_CKSUM;

i40e PMD will support both B.1 and B.2, but ixgbe/igb/em PMD supports only B.2.
if HW supports both - it will be up to user app which method to choose.
tespmd will support both methods, and it should be configurable by user which 
approach to use (cmdline parameter).
So the user can try/test both methods and select an appropriate for him.

C) User knows that is a tunnelled packet, and wants HW offload for all 3 
checksums:  outer IP hdr checksum, inner IP checksum, inner TCP checksum.
Then he has to setup all TX checksum fields:
 mb->l2_len =  udp_hdr_out + vxlan_hdr +eth_hdr_in;;
 mb->l3_len = ipv4_hdr_in;
 mb->outer_l2_len = eth_hdr_out;
 mb->outer_l3_len = ipv4_hdr_out;
 mb->ol_flags |= PKT_TX_OUT_IP_CKSUM  | PKT_TX_UDP_TUNNEL_PKT | 
PKT_TX_IP_CKSUM |  PKT_TX_TCP_CKSUM;

Change notes:
v2 changes:
 remove PKT_TX_IP_CKSUM alias.
 add PKT_TX_OUT_IP_CKSUM and PKT_TX_OUTER_IPV6 in rte_get_tx_ol_flag_name.
 spliting mbuf changes into two patches.
 fix MACLEN caculation issue in i40e driver
 fix some issues in csumonly.c
 change cover letter.
v3 changes:
 fix MACLEN caculation issue in i40e driver when non-tunneling packet 
v4 changes:
 reorganize patches to avoid compilation to be broken between patches.
 remove l4_tun_len from mbuf structure.
 add PKT_TX_OUTER_IPV4 to indicate no IP checksum offload requirement for 
tunneling packet.
 change i40e PMD and csum engine due to above changes.

Jijiang Liu (3):
  Redefine PKT_TX_IPV4, PKT_TX_IPV6 and PKT_TX_VLAN_PKT;
  Replace PKT_TX_VXLAN_CKSUM with PKT_TX_UDP_TUNNEL_PKT, and add 3 TX flags, 
which are PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IPV4 and PKT_TX_OUTER_IPV6,and 
rework csum forward engine and i40e pmd due to these changes;
  Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and 
outer_l3_len field, and rework csum forward engine and i40e pmd due to  these 
changes;

 app/test-pmd/csumonly.c |   69 ++
 lib/librte_mbuf/rte_mbuf.c  |7 +++-
 lib/librte_mbuf/rte_mbuf.h  |   25 +
 lib/librte_pmd_i40e/i40e_rxtx.c |   44 +
 4 files changed, 86 insertions(+), 59 deletions(-)

-- 
1.7.7.6

[dpdk-dev] [PATCH] Doc: Adding Distributor Sample Application to Sample App UG

[Siobhan Butler]

New distributor sample app user guide section for sample app ug.

Signed-off-by: Siobhan Butler 
---
 doc/guides/sample_app_ug/dist_app.rst  | 173 +++
 doc/guides/sample_app_ug/img/dist_app.svg  | 442 +++
 doc/guides/sample_app_ug/img/dist_perf.svg | 459 +
 doc/guides/sample_app_ug/index.rst |   5 +
 4 files changed, 1079 insertions(+)
 create mode 100644 doc/guides/sample_app_ug/dist_app.rst
 create mode 100644 doc/guides/sample_app_ug/img/dist_app.svg
 create mode 100644 doc/guides/sample_app_ug/img/dist_perf.svg

diff --git a/doc/guides/sample_app_ug/dist_app.rst 
b/doc/guides/sample_app_ug/dist_app.rst
new file mode 100644
index 000..3064ff8
--- /dev/null
+++ b/doc/guides/sample_app_ug/dist_app.rst
@@ -0,0 +1,173 @@
+..  BSD LICENSE
+Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Distributor Sample Application
+==
+
+The distributor sample application is a simple example of packet distribution
+to cores using the Data Plane Development Kit (DPDK).
+
+Overview
+
+
+The distributor application performs the distribution of packets that are 
received
+on an RX_PORT to different cores. When processed by the cores, the destination
+port of a packet is the port from the enabled port mask adjacent to the one on
+which the packet was received, that is, if the first four ports are enabled
+(port mask 0xf), ports 0 and 1 RX/TX into each other, and ports 2 and 3 RX/TX
+into each other.
+
+This application can be used to benchmark performance using the traffic
+generator as shown in the figure below.
+
+.. _figure_22:
+
+**Figure 22. Performance Benchmarking Setup (Basic Environment)**
+
+|dist_perf|
+
+Compiling the Application
+-
+
+#.  Go to the sample application directory:
+
+..  code-block:: console
+
+export RTE_SDK=/path/to/rte_sdk
+cd ${RTE_SDK}/examples/l3fwd-acl
+
+#.  Set the target (a default target is used if not specified). For example:
+
+..  code-block:: console
+
+export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+See the DPDK Getting Started Guide for possible RTE_TARGET values.
+
+#.  Build the application:
+
+..  code-block:: console
+
+make
+
+Running the Application
+---
+
+#. The application has a number of command line options:
+
+..  code-block:: console
+
+./build/distributor_app [EAL options] -- -p PORTMASK
+
+where,
+
+*   -p PORTMASK: Hexadecimal bitmask of ports to configure
+
+#. To run the application in linuxapp environment with 11 lcores, 4 ports,
+issue the command:
+
+..  code-block:: console
+
+ $ ./build/distributor_app -c 0x4003fe -n 4 -- -p f
+
+#. Refer to the DPDK Getting Started Guide for general information on running
+applications and the Environment Abstraction Layer (EAL) options.
+
+Explanation
+---
+
+The distributor application consists of three types of threads: a receive
+thread (lcore_rx()), a set of worker threads(locre_worker())
+and a transmit thread(lcore_tx()).How these threads work together is shown
+in Fig2 below. The main() function launches  threads of these three types.
+Each thread has a while loop which will be doing processing and which is
+terminated only upon SIGINT or ctrl+C. The receive and transmit threads
+communicate using a software ring (rte_ring structure).
+
+The receiv

[dpdk-dev] Error running dpdk app: cannot open /dev/uio

[Malveeka Tewari]

Hi

I am trying to run the testpmd app as but I get the following errors:
EAL: VFIO could not be initialized
EAL: Cannot open /dev/uio0: No such file or directory
EAL: Error - exiting with code: 1
  Cause: Requested device :07:00.0 cannot be used

lsmod shows that the uio module is installed.
Is there anything that's missing?

Thanks!
Malveeka



Output on trying to run testpmd

EAL: Detected 16 lcore(s)
*EAL:   cannot open VFIO container, error 2 (No such file or directory)*
*EAL: VFIO support could not be initialized*
EAL: Setting up memory...
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fe66ac0 (size = 0x20)
EAL: Ask a virtual area of 0xffc0 bytes
EAL: Virtual area found at 0x7fe56ae0 (size = 0xffc0)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fe56aa0 (size = 0x20)
EAL: Ask a virtual area of 0xfec0 bytes
EAL: Virtual area found at 0x7fe46bc0 (size = 0xfec0)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7fe46b60 (size = 0x40)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7fe46b00 (size = 0x40)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7fe46aa0 (size = 0x40)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7fe46a40 (size = 0x40)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7fe469e0 (size = 0x40)
EAL: Requesting 2048 pages of size 2MB from socket 0
EAL: Requesting 2048 pages of size 2MB from socket 1
EAL: TSC frequency is ~2266745 KHz
EAL: Master core 3 is ready (tid=6cedb800)
EAL: PCI device :07:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10fb rte_ixgbe_pmd


*EAL: Cannot open /dev/uio0: No such file or directoryEAL: Error - exiting
with code: 1  Cause: Requested device :07:00.0 cannot be used*

[dpdk-dev] [PATCH v8 0/4] Support configuring hash functions

[Ananyev, Konstantin]

> -Original Message-
> From: Zhang, Helin
> Sent: Tuesday, December 02, 2014 2:19 AM
> To: dev at dpdk.org
> Cc: Cao, Waterman; Cao, Min; Ananyev, Konstantin; Zhang, Helin
> Subject: [PATCH v8 0/4] Support configuring hash functions
> 
> These patches mainly support configuring hash functions. In detail,
>  - It can get/set global hash configurations.
>   * Get/set symmetric hash enable per flow type.
>   * Get/set hash function type.
>  - It can get/set symmetric hash enable per port.
>  - Four commands have been implemented in testpmd to support testing above.
>* get_sym_hash_ena_per_port
>* set_sym_hash_ena_per_port
>* get_hash_global_config
>* set_hash_global_config
> 
> It also uses constant hash keys to replace runtime generating hash keys.
> Global initialization is added to correctly put registers to an initial state.
> 
> v3 changes:
> * Removed renamings in rte_ethdev.h.
> * Redesigned filter control API and its relevant structures/enums.
> * Renamed header file from rte_eth_features.h to rte_eth_ctrol.h.
> * Remove public header file of rte_i40e.h specific for i40e.
> * Added hardware initialization function during port init.
> * Used constant random hash keys in i40e PF.
> * renamed the commands in testpmd based on the redesigned filter control API.
> 
> v4 changes:
> * Fixed a bug in testpmd to support 'set_sym_hash_ena_per_port'.
> 
> v5 changes:
> * Integrated with filter API defined recently.
> * Remove all for filter API definition, as it has already defined and merged
>   recently.
> 
> v6 changes:
> * Flow type strings are used to replace Packet Classification Types, to 
> isolate
>   hardware specific things.
> * Implemented the mapping function to convert RSS offload types to Packet
>   Classification Types, to isolate the real hardware specific things.
> * Removed initialization of global registers in i40e PMD, as global registers
>   shouldn't be initialized per port.
> * Added more annotations to get code more understandable.
> * Corrected annotation format for documenation.
> 
> v7 changes:
> * Removed swap configurations, as it is not allowed by hardware design.
> * Put symmetric hash per flow type and hash function type into
>   'RTE_ETH_HASH_FILTER_GLOBAL_CONFIG', as they are controlling global 
> registers
>   which will affects all the ports of the same NIC.
> 
> v8 changes:
> * Removed redundant checks in i40e_ethdev.c.
> * Solved compile errors on ICC.
> 
> Helin Zhang (4):
>   ethdev: code style fixes
>   i40e: use constant as the default hash keys
>   i40e: support of controlling hash functions
>   app/testpmd: add commands to support hash functions
> 
>  app/test-pmd/cmdline.c| 333 
> ++
>  lib/librte_ether/rte_eth_ctrl.h   |  72 -
>  lib/librte_pmd_i40e/i40e_ethdev.c | 308 +--
>  3 files changed, 699 insertions(+), 14 deletions(-)
> 
> --
> 1.8.1.4

Acked-by: Konstantin Ananyev 

[dpdk-dev] [PATCH] lpm: fix maybe-uninitialized warning when using LTO during compilation

[Thomas Monjalon]

> > This patch fixes a maybe-uninitialized warning when compiling DPDK with
> > GCC 4.9 + Link Time Optimization.
> > 
> > Signed-off-by: Dennis Marinus 
> 
> Acked-by: Bruce Richardson 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] ixgbe: fix build with bypass and debug enabled

[Thomas Monjalon]

> > Since commit aae1047905621 ("use the right debug macro"),
> > DEBUGOUT was replaced by PMD_DRV_LOG which requires at least
> > 2 arguments. But the level argument was missing.
> >
> > Commit 7a10de5e27 fixed the logs but not the macros FUNC_PTR_OR_*
> > which are not preprocessed if RTE_LIBRTE_IXGBE_DEBUG_DRIVER is disabled.
> >
> > Signed-off-by: Thomas Monjalon 
> 
> Argh ... good catch.
> Looks like these were the only places with this error (I did some grep and
> only found those).
> And ok with the ERR level, it looks fine to me.
> 
> Ack.

Applied

-- 
Thomas

[dpdk-dev] [PATCH] doc: link bonding related updates to programmers guide

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty
> Sent: Monday, December 1, 2014 5:10 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: link bonding related updates to programmers 
> guide
> 
> Adding details for link status interrupts and link status polling.
> Adding details for mode 4 / mode 5
> Tidying up rst document to conform to 80 character line limit
> Adding diagrams to explain bonding modes
> 
> Signed-off-by: Declan Doherty 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v2 1/2] igb_uio: compatible with upstream longterm kernel and RHEL6

[Jincheng Miao]

On 11/29/2014 12:42 AM, Thomas Monjalon wrote:
> 2014-11-28 16:13, Jincheng Miao:
>> On 11/28/2014 01:01 AM, Thomas Monjalon wrote:
>>> 2014-10-31 15:37, Jincheng Miao:
 Function pci_num_vf() is introduced from upstream linux-2.6.34. So
 this patch make compatible with longterm kernel linux-2.6.32.63.

 For RHEL6's kernel, although it is based on linux-2.6.32, it has
 pci_num_vf() implementation. As the same with commit 11ba0426,
 pci_num_vf() is defined from RHEL6. So we should check the macro
 RHEL_RELEASE_CODE to consider this situation.
>>> Please, could you explain in which case CONFIG_PCI_IOV is defined?
>>> The logic is a bit difficult to understand.
>> Yep, there is a little confusion for pci_num_vf():
>> 1. it is available when CONFIG_PCI_IOV is defined.
>> 2. it is introduced from upstream kernel v2.6.34 (fb8a0d9)
>> 3. it is implemented from RHEL6.0, although the kernel version is 2.6.32.
> Sorry, you didn't described when CONFIG_PCI_IOV is defined.
> Is it defined since 2.6.34 upstream? In lower stable versions?
> Is it defined since RHEL 6.0?
> Why checking CONFIG_PCI_IOV is not sufficient?
>
> When pci_num_vf will be backported in other distributions, we will have to
> tune this check and clearly understand what was the situation.

I am not the expert on this, the only thing I know is:
CONFIG_PCI_IOV is config switch for the I/O device virtualization, it will
enable some SRIOV feature for PCI devices supports IO virtualization.
It is defined since upstream kernel v2.6.30 (d1b054d).

But as you said, function pci_num_vf() is stub-defined in kernel when
CONFIG_PCI_IOV disabled. So checking CONFIG_PCI_IOV is meaningless
for pci_num_vf().

For the function pci_num_vf(), I wrote it is defined since RHEL6.0.
But after some searching, I found the earliest is RHEL5 Update9
kernel-devel-2.6.18-348.el5.x86_64.rpm.

I think it should be modified to:
```
  #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
-!defined(CONFIG_PCI_IOV)
+   (!(defined(RHEL_RELEASE_CODE) && \
+  RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(5, 9)))
```

After that, if there is other distro need to be compatible,
we could simply add condition bellow:
(!(defined(OTHER_RELEASE_CODE) && OTHER_RELEASE_CODE >= 
OTHER_RELEASE_VERSION(X, Y)))


Thanks for your patient for pointing out the issue of my patch.
Jincheng Miao

>> The logic of this patch is:
>> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
>> (!(defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >=
>> RHEL_RELEASE_VERSION(6, 0) && defined(CONFIG_PCI_IOV)))
>>
>> Firstly it detects kernel version, if it is less than 2.6.34, and it is
>> not RHEL-specified, then define pci_num_vf().
>>
>> Secondly, it deals with RHEL-specified. If it is RHEL6.0 or later, and
>> CONFIG_PCI_IOV is defined. we should not define pci_num_vf(). If any of
>> these conditions is not reached, pci_num_vf() should be defined.
> I can read the check but I don't know why CONFIG_PCI_IOV is checked in the
> RHEL case.
>
>> Some days ago, I setup dpdk for longterm kernel 2.6.32.63, and got error:
>> ```
>> CC [M]
>> /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o
>> /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:
>> In function ?show_max_vfs?:
>> /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:75:
>> error: implicit declaration of function ?pci_num_vf?
>> ```
> Thank you. Describing the problem is helpful for the commit log.
>   
>> This problem is introduced by commit 11ba04265
>>
>> commit 11ba04265cfd2a53c12c030fcaa5dfe7eed39a42
>> Author: Guillaume Gaudonville
>> Date: Wed Sep 3 10:18:23 2014 +0200
>>
>> igb_uio: fix build on RHEL 6.3
>>
>> - pci_num_vf() is already defined in RHEL 6
>> - pci_intx_mask_supported is already defined in RHEL 6.3
>> - pci_check_and_mask_intx is already defined in RHEL 6.3
>>
>> Signed-off-by: Guillaume Gaudonville
>> Signed-off-by: David Marchand
>> Signed-off-by: Thomas Monjalon
>>
>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
>> + !defined(CONFIG_PCI_IOV)
>>
>> That is because longterm kernel 2.6.32.63 defined CONFIG_PCI_IOV, but it
>> lacks pci_num_vf(),
>> after above processing, pci_num_vf() is still not existed, then build fail.
>>
>> My patch could work around it, and can deal with RHEL-specified kernel.
> Thanks, we just need to understand the matrix of combinations to be sure
> it will be well maintained.
>

[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[Tetsuya Mukawa]

, so if
>> you're using Linux then you need to use option 2 below.
>>> 2. You can join using a phone via one of the numbers listed below. The
>> Access Code is 772-753-069. You'll also be asked for an Audio PIN, which is
>> accessible by clicking the phone icon in the GoToMeeting web viewer after
>> you've joined the meeting.
>>> ? Australia   (Long distance): +61 2 9091 7601
>>> ? Austria   (Long distance): +43 (0) 7 2088 1036
>>> ? Belgium   (Long distance): +32 (0) 28 08 4345
>>> ? Canada   (Long distance): +1 (647) 497-9372
>>> ? Denmark   (Long distance): +45 (0) 69 91 89 24
>>> ? Finland   (Long distance): +358 (0) 942 45 0382
>>> ? France   (Long distance): +33 (0) 170 950 586
>>> ? Germany   (Long distance): +49 (0) 692 5736 7206
>>> ? Ireland   (Long distance): +353 (0) 15 255 598
>>> ? Italy   (Long distance): +39 0 694 80 31 28
>>> ? Netherlands   (Long distance): +31 (0) 208 084 055
>>> ? New Zealand   (Long distance): +64 (0) 4 974 7243
>>> ? Norway   (Long distance): +47 23 96 01 18
>>> ? Spain   (Long distance): +34 932 20 0506
>>> ? Sweden   (Long distance): +46 (0) 852 500 182
>>> ? Switzerland   (Long distance): +41 (0) 435 0824 78
>>> ? United Kingdom   (Long distance): +44 (0) 330 221 0098
>>> ? United States   (Long distance): +1 (626) 521-0013
>>> Access Code 772-753-069.
>>>
>>> Info on downloading the desktop app is available at:
>> http://support.citrixonline.com/en_US/meeting/help_files/G2M010002?title
>> =Download%7D
>>> Info on the web viewer is available at:
>> http://support.citrixonline.com/en_US/GoToMeeting/help_files/GTM13001
>> 9?title=Web+Viewer+FAQs
>>>
>>> Thanks,
>>> Tim

-- next part --
A non-text attachment was scrubbed...
Name: Current Progress of DPDK Port Hotplug Framework.pdf
Type: application/pdf
Size: 99108 bytes
Desc: not available
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20141202/4ff92b7e/attachment-0001.pdf>

[dpdk-dev] [PATCH v2] kni: create KNI interface in current network namespace

[Takayuki Usui]

With this patch, KNI interface (e.g. vEth0) is created in the
network namespace where the DPDK application is running.
Otherwise, all interfaces are created in the default namespace
in the host.

put_net() is required, since get_net_ns_by_pid() increments
the reference counter of the network namespace with get_net().

Signed-off-by: Takayuki Usui 
---
 lib/librte_eal/linuxapp/kni/kni_misc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index ba6..33c7a48 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -311,6 +311,7 @@ kni_ioctl_create(unsigned int ioctl_num, unsigned long 
ioctl_param)
struct net_device *net_dev = NULL;
struct net_device *lad_dev = NULL;
struct kni_dev *kni, *dev, *n;
+   struct net *net;

printk(KERN_INFO "KNI: Creating kni...\n");
/* Check the buffer size, to avoid warning */
@@ -354,6 +355,12 @@ kni_ioctl_create(unsigned int ioctl_num, unsigned long 
ioctl_param)
return -EBUSY;
}

+   net = get_net_ns_by_pid(current->pid);
+   if (IS_ERR(net))
+   return PTR_ERR(net);
+   dev_net_set(net_dev, net);
+   put_net(net);
+
kni = netdev_priv(net_dev);

kni->net_dev = net_dev;
-- 
2.1.3

[dpdk-dev] [PATCH] add one option memory-only for those secondary PRBs

[Thomas Monjalon]

Hi,

2014-12-02 09:55, Chi, Xiaobo:
> Problem:
> Here, these DPDK based SECONDARY processes need only the DPDK's hugepage
> based sharememory mechanism and it's upper libs (such as ring, mempool,
> etc.), they need not cpu core pinning, iopl privilege changing , pci device,
> timer, alarm, interrupt, shared_driver_list,  core_info, threads for each
> core, etc. Then, for such kind of SECONDARY processes, the current
> rte_eal_init() is too heavy.  
> I have seen some others also met similar troubles. 
> 
> Solution:
> One new EAL initializing argument, --memory-only, is added. It is only for
> those SECONDARY processes which only want to share memory with primary
> process. When this argument is defined, users need not define those
> madentory arguments, such as "-c xx -n xx", due to we don't want to pin such
> kind of processes to any CPUs.

That's exactly the type of things that you should put in the commit log.
It misses also a Signed-off-by.
All guidelines are explained in this page:
http://dpdk.org/dev#send

Please check your patch with checkpatch for indentation and other details.

-- 
Thomas

[dpdk-dev] endianness with ICC

[Neil Horman]

On Tue, Dec 02, 2014 at 04:36:20PM +0100, Thomas Monjalon wrote:
> I'm looking at endian detection to make it work with several compilers.
> 
> During this global check, I've seen some code specific to ICC:
>   http://dpdk.org/browse/dpdk/tree/app/test-pmd/testpmd.h#n562
> If it's still really useful, it should in rte_byteorder.h, not in testpmd.
> 
> But, if possible, I'd prefer to remove this workaround.
> 
> Any opinion?
> 
No objections
Neil

> -- 
> Thomas
> 

[dpdk-dev] [PATCH] add one option memory-only for those secondary PRBs

[Bruce Richardson]

On Tue, Dec 02, 2014 at 05:41:08PM +0800, chixiaobo wrote:
> ---
>  lib/librte_eal/common/eal_common_options.c |  18 +++-
>  lib/librte_eal/common/eal_internal_cfg.h   |   1 +
>  lib/librte_eal/common/eal_options.h|   4 +-
>  lib/librte_eal/linuxapp/eal/eal.c  | 137 
> +++--
>  4 files changed, 89 insertions(+), 71 deletions(-)
>  mode change 100644 => 100755 lib/librte_eal/common/eal_common_options.c
>  mode change 100644 => 100755 lib/librte_eal/common/eal_internal_cfg.h
>  mode change 100644 => 100755 lib/librte_eal/common/eal_options.h
>  mode change 100644 => 100755 lib/librte_eal/linuxapp/eal/eal.c
> 
> diff --git a/lib/librte_eal/common/eal_common_options.c 
> b/lib/librte_eal/common/eal_common_options.c
> old mode 100644
> new mode 100755
> index e2810ab..5ab4b87



> diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
> b/lib/librte_eal/linuxapp/eal/eal.c
> old mode 100644
> new mode 100755
> index 89f3b5e..a03e511
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -752,14 +752,16 @@ rte_eal_init(int argc, char **argv)
>  
>   rte_config_init();
>  
> - if (rte_eal_pci_init() < 0)
> - rte_panic("Cannot init PCI\n");
> +/*with memory-only option, we need not cpu affinity, pci device, alarm, 
> external devices, interrupt, etc. */
> +if( !internal_config.memory_only ){
> + if (rte_eal_pci_init() < 0)
> + rte_panic("Cannot init PCI\n");
>  
>  #ifdef RTE_LIBRTE_IVSHMEM
>   if (rte_eal_ivshmem_init() < 0)
>   rte_panic("Cannot init IVSHMEM\n");
>  #endif
> -
> +}
>   if (rte_eal_memory_init() < 0)
>   rte_panic("Cannot init memory\n");
>  
> @@ -772,73 +774,73 @@ rte_eal_init(int argc, char **argv)
>   if (rte_eal_tailqs_init() < 0)
>   rte_panic("Cannot init tail queues for objects\n");
>  

At this point, I believe you are finished the initialization for the
memory only case, so instead of adding all the rest of the content below to 
an "if" statement and indenting it further, I think it would be better to have
a single short "if" statement here for "if (internal_config.memory_only) return"
leaving the rest of the existing function unmodified.

> -#ifdef RTE_LIBRTE_IVSHMEM
> - if (rte_eal_ivshmem_obj_init() < 0)
> - rte_panic("Cannot init IVSHMEM objects\n");
> -#endif
> -
>   if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0)
>   rte_panic("Cannot init logs\n");
>  
> - if (rte_eal_alarm_init() < 0)
> - rte_panic("Cannot init interrupt-handling thread\n");
> -
> - if (rte_eal_intr_init() < 0)
> - rte_panic("Cannot init interrupt-handling thread\n");
> -
> - if (rte_eal_timer_init() < 0)
> - rte_panic("Cannot init HPET or TSC timers\n");
> -
> - eal_check_mem_on_local_socket();
> -
> - rte_eal_mcfg_complete();
> -
> - TAILQ_FOREACH(solib, &solib_list, next) {
> - RTE_LOG(INFO, EAL, "open shared lib %s\n", solib->name);
> - solib->lib_handle = dlopen(solib->name, RTLD_NOW);
> - if (solib->lib_handle == NULL)
> - RTE_LOG(WARNING, EAL, "%s\n", dlerror());
> - }
> -
> - eal_thread_init_master(rte_config.master_lcore);
> -
> - RTE_LOG(DEBUG, EAL, "Master core %u is ready (tid=%x)\n",
> - rte_config.master_lcore, (int)thread_id);
> -
> - if (rte_eal_dev_init() < 0)
> - rte_panic("Cannot init pmd devices\n");
> -
> - RTE_LCORE_FOREACH_SLAVE(i) {
> -
> - /*
> -  * create communication pipes between master thread
> -  * and children
> -  */
> - if (pipe(lcore_config[i].pipe_master2slave) < 0)
> - rte_panic("Cannot create pipe\n");
> - if (pipe(lcore_config[i].pipe_slave2master) < 0)
> - rte_panic("Cannot create pipe\n");
> -
> - lcore_config[i].state = WAIT;
> -
> - /* create a thread for each lcore */
> - ret = pthread_create(&lcore_config[i].thread_id, NULL,
> -  eal_thread_loop, NULL);
> - if (ret != 0)
> - rte_panic("Cannot create thread\n");
> - }
> -
> - /*
> -  * Launch a dummy function on all slave lcores, so that master lcore
> -  * knows they are all ready when this function returns.
> -  */
> - rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
> - rte_eal_mp_wait_lcore();
> -
> - /* Probe & Initialize PCI devices */
> - if (rte_eal_pci_probe())
> - rte_panic("Cannot probe PCI\n");
> -
> +if( !internal_config.memory_only ){
> +#ifdef RTE_LIBRTE_IVSHMEM
> +if (rte_eal_ivshmem_obj_init() < 0)
> +rte_panic("Cannot init IVSHMEM objects\n");
> +#endif
> +if (rte_eal_alarm_init() < 0)
> + rte_panic("Cannot init interrupt-h

[dpdk-dev] [PATCH v8 4/4] app/testpmd: add commands to support hash functions

[Helin Zhang]

To demonstrate the hash filter control, commands are added.
They are,
- get_sym_hash_ena_per_port
- set_sym_hash_ena_per_port
- get_hash_global_config
- set_hash_global_config

Signed-off-by: Helin Zhang 
---
 app/test-pmd/cmdline.c | 333 +
 1 file changed, 333 insertions(+)

v6 changes:
* Flow type strings are used to replace Packet Classification Types, to isolate
  hardware specific things.

v7 changes:
* Removed commands of,
  get_sym_hash_ena_per_pctype
  set_sym_hash_ena_per_pctype
  get_filter_swap
  set_filter_swap
  get_hash_function
  set_hash_function.
* Added new commands of,
  get_hash_global_config
  set_hash_global_config

v8 changes:
* Fixed the compile issue on ICC, of "error #188: enumerated type mixed with
  another type".

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index c61c3a0..f1b92a7 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -75,6 +75,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -740,6 +741,21 @@ static void cmd_help_long_parsed(void *parsed_result,
"flow_director_flex_payload (port_id)"
" (l2|l3|l4) (config)\n"
"Configure flex payload selection.\n\n"
+
+   "get_sym_hash_ena_per_port (port_id)\n"
+   "get symmetric hash enable configuration per 
port.\n\n"
+
+   "set_sym_hash_ena_per_port (port_id) (enable|disable)\n"
+   "set symmetric hash enable configuration per port"
+   " to enable or disable.\n\n"
+
+   "get_hash_global_config (port_id)\n"
+   "Get the global configurations of hash filters.\n\n"
+
+   "set_hash_global_config (port_id) 
(toeplitz|simple_xor|default)"
+   " 
(ip4|ip4-frag|tcp4|udp4|#sctp4|ip6|ip6-frag|tcp6|udp6|sctp6)"
+   " (enable|disable)\n"
+   "Set the global configurations of hash filters.\n\n"
);
}
 }
@@ -8697,6 +8713,319 @@ cmdline_parse_inst_t cmd_set_flow_director_flex_payload 
= {
},
 };

+/* *** Classification Filters Control *** */
+/* *** Get symmetric hash enable per port *** */
+struct cmd_get_sym_hash_ena_per_port_result {
+   cmdline_fixed_string_t get_sym_hash_ena_per_port;
+   uint8_t port_id;
+};
+
+static void
+cmd_get_sym_hash_per_port_parsed(void *parsed_result,
+__rte_unused struct cmdline *cl,
+__rte_unused void *data)
+{
+   struct cmd_get_sym_hash_ena_per_port_result *res = parsed_result;
+   struct rte_eth_hash_filter_info info;
+   int ret;
+
+   if (rte_eth_dev_filter_supported(res->port_id,
+   RTE_ETH_FILTER_HASH) < 0) {
+   printf("RTE_ETH_FILTER_HASH not supported on port: %d\n",
+   res->port_id);
+   return;
+   }
+
+   memset(&info, 0, sizeof(info));
+   info.info_type = RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT;
+   ret = rte_eth_dev_filter_ctrl(res->port_id, RTE_ETH_FILTER_HASH,
+   RTE_ETH_FILTER_GET, &info);
+
+   if (ret < 0) {
+   printf("Cannot get symmetric hash enable per port "
+   "on port %u\n", res->port_id);
+   return;
+   }
+
+   printf("Symmetric hash is %s on port %u\n", info.info.enable ?
+   "enabled" : "disabled", res->port_id);
+}
+
+cmdline_parse_token_string_t cmd_get_sym_hash_ena_per_port_all =
+   TOKEN_STRING_INITIALIZER(struct cmd_get_sym_hash_ena_per_port_result,
+   get_sym_hash_ena_per_port, "get_sym_hash_ena_per_port");
+cmdline_parse_token_num_t cmd_get_sym_hash_ena_per_port_port_id =
+   TOKEN_NUM_INITIALIZER(struct cmd_get_sym_hash_ena_per_port_result,
+   port_id, UINT8);
+
+cmdline_parse_inst_t cmd_get_sym_hash_ena_per_port = {
+   .f = cmd_get_sym_hash_per_port_parsed,
+   .data = NULL,
+   .help_str = "get_sym_hash_ena_per_port port_id",
+   .tokens = {
+   (void *)&cmd_get_sym_hash_ena_per_port_all,
+   (void *)&cmd_get_sym_hash_ena_per_port_port_id,
+   NULL,
+   },
+};
+
+/* *** Set symmetric hash enable per port *** */
+struct cmd_set_sym_hash_ena_per_port_result {
+   cmdline_fixed_string_t set_sym_hash_ena_per_port;
+   cmdline_fixed_string_t enable;
+   uint8_t port_id;
+};
+
+static void
+cmd_set_sym_hash_per_port_parsed(void *parsed_result,
+__rte_unused struct cmdline *cl,
+__rte_unused void *data)
+{
+   struct cmd_set_sym_hash_ena_per_port_result *res = parsed_result;
+   struct rte_eth_hash_filter_info

[dpdk-dev] [PATCH v8 3/4] i40e: support of controlling hash functions

[Helin Zhang]

Hash filter control has been implemented for i40e. It includes
getting/setting,
- global hash configurations (hash function type, and symmetric
  hash enable per flow type)
- symmetric hash enable per port

Signed-off-by: Helin Zhang 
---
 lib/librte_ether/rte_eth_ctrl.h   |  63 
 lib/librte_pmd_i40e/i40e_ethdev.c | 294 +-
 2 files changed, 355 insertions(+), 2 deletions(-)

v5 changes:
* Integrated with filter API defined recently.

v6 changes:
* Implemented the mapping function to convert RSS offload types to Packet
  Classification Types, to isolate the real hardware specific things.
* Removed initialization of global registers in i40e PMD, as global registers
  shouldn't be initialized per port.
* Added more annotations to get code more understandable.
* Corrected annotation format for documenation.

v7 changes:
* Removed swap configurations, as it is not allowed by hardware design.
* Put symmetric hash per flow type and hash function type into
  'RTE_ETH_HASH_FILTER_GLOBAL_CONFIG', as they are controlling global registers
  which will affects all the ports of the same NIC.

v8 changes:
* Removed redundant return value checks of i40e_flowtype_to_pctype(), as it
  should always be correct.
* Fixed the compile issue on ICC, of "error #188: enumerated type mixed with
  another type".

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 6ab16c2..827d7ba 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -55,6 +55,7 @@ enum rte_filter_type {
RTE_ETH_FILTER_ETHERTYPE,
RTE_ETH_FILTER_TUNNEL,
RTE_ETH_FILTER_FDIR,
+   RTE_ETH_FILTER_HASH,
RTE_ETH_FILTER_MAX
 };

@@ -449,6 +450,68 @@ struct rte_eth_fdir_stats {
uint32_t best_cnt; /**< Number of filters in best effort spaces. */
 };

+/**
+ * Hash filter information types.
+ * - RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT is for getting/setting the
+ *   information/configuration of 'symmetric hash enable' per port.
+ * - RTE_ETH_HASH_FILTER_GLOBAL_CONFIG is for getting/setting the global
+ *   configurations of hash filters. Those global configurations are valid
+ *   for all ports of the same NIC.
+ */
+enum rte_eth_hash_filter_info_type {
+   RTE_ETH_HASH_FILTER_INFO_TYPE_UNKNOWN = 0,
+   /** Symmetric hash enable per port */
+   RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT,
+   /** Configure globally for hash filter */
+   RTE_ETH_HASH_FILTER_GLOBAL_CONFIG,
+   RTE_ETH_HASH_FILTER_INFO_TYPE_MAX,
+};
+
+/**
+ * Hash function types.
+ */
+enum rte_eth_hash_function {
+   RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
+   RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
+   RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+   RTE_ETH_HASH_FUNCTION_MAX,
+};
+
+#define UINT32_BIT (CHAR_BIT * sizeof(uint32_t))
+#define RTE_SYM_HASH_MASK_ARRAY_SIZE \
+   (RTE_ALIGN(RTE_ETH_FLOW_TYPE_MAX, UINT32_BIT)/UINT32_BIT)
+/**
+ * A structure used to set or get global hash function configurations which
+ * include symmetric hash enable per flow type and hash function type.
+ * Each bit in sym_hash_enable_mask[] indicates if the symmetric hash of the
+ * coresponding flow type is enabled or not.
+ * Each bit in valid_bit_mask[] indicates if the coresponding bit in
+ * sym_hash_enable_mask[] is valid or not. For the configurations gotten, it
+ * also means if the flow type is supported by hardware or not.
+ */
+struct rte_eth_hash_global_conf {
+   enum rte_eth_hash_function hash_func; /**< Hash function type */
+   /** Bit mask for symmetric hash enable per flow type */
+   uint32_t sym_hash_enable_mask[RTE_SYM_HASH_MASK_ARRAY_SIZE];
+   /** Bit mask indicates if the coresponding bit is valid */
+   uint32_t valid_bit_mask[RTE_SYM_HASH_MASK_ARRAY_SIZE];
+};
+
+/**
+ * A structure used to set or get hash filter information, to support filter
+ * type of 'RTE_ETH_FILTER_HASH' and its operations.
+ */
+struct rte_eth_hash_filter_info {
+   enum rte_eth_hash_filter_info_type info_type; /**< Information type. */
+   /** Details of hash filter infomation */
+   union {
+   /* For RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT */
+   uint8_t enable;
+   /* Global configurations of hash filter */
+   struct rte_eth_hash_global_conf global_conf;
+   } info;
+};
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 8fbe25f..fa9cac8 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -93,6 +93,18 @@
I40E_PFINT_ICR0_ENA_VFLR_MASK | \
I40E_PFINT_ICR0_ENA_ADMINQ_MASK)

+#define I40E_FLOW_TYPES ( \
+   (1UL << RTE_ETH_FLOW_TYPE_UDPV4) | \
+   (1UL << RTE_ETH_FLOW_TYPE_TCPV4) | \
+   (1UL << RTE_ETH_FLOW_TYPE_SCTPV4) | \
+   (1UL << RTE_ETH_FLOW_TYPE_IPV4_OTHER) | \
+   (1

[dpdk-dev] [PATCH v8 2/4] i40e: use constant as the default hash keys

[Helin Zhang]

Calculating the default RSS hash keys at run time is not needed
at all, and may have race conditions. The alternative is to use
array of random values which were generated manually as the
default hash keys.

Signed-off-by: Helin Zhang 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 87e750a..8fbe25f 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -73,7 +73,7 @@
 /* Maximun number of VSI */
 #define I40E_MAX_NUM_VSIS  (384UL)

-/* Default queue interrupt throttling time in microseconds*/
+/* Default queue interrupt throttling time in microseconds */
 #define I40E_ITR_INDEX_DEFAULT  0
 #define I40E_QUEUE_ITR_INTERVAL_DEFAULT 32 /* 32 us */
 #define I40E_QUEUE_ITR_INTERVAL_MAX 8160 /* 8160 us */
@@ -199,9 +199,6 @@ static int i40e_dev_filter_ctrl(struct rte_eth_dev *dev,
enum rte_filter_op filter_op,
void *arg);

-/* Default hash key buffer for RSS */
-static uint32_t rss_key_default[I40E_PFQF_HKEY_MAX_INDEX + 1];
-
 static struct rte_pci_id pci_id_i40e_map[] = {
 #define RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
 #include "rte_pci_dev_ids.h"
@@ -5023,9 +5020,12 @@ i40e_pf_config_rss(struct i40e_pf *pf)
}
if (rss_conf.rss_key == NULL || rss_conf.rss_key_len <
(I40E_PFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t)) {
-   /* Calculate the default hash key */
-   for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
-   rss_key_default[i] = (uint32_t)rte_rand();
+   /* Random default keys */
+   static uint32_t rss_key_default[] = {0x6b793944,
+   0x23504cb5, 0x5bea75b6, 0x309f4f12, 0x3dc0a2b8,
+   0x024ddcdf, 0x339b8ca0, 0x4c4af64a, 0x34fac605,
+   0x55d85839, 0x3a58997d, 0x2ec938e1, 0x66031581};
+
rss_conf.rss_key = (uint8_t *)rss_key_default;
rss_conf.rss_key_len = (I40E_PFQF_HKEY_MAX_INDEX + 1) *
sizeof(uint32_t);
-- 
1.8.1.4

[dpdk-dev] [PATCH v8 1/4] ethdev: code style fixes

[Helin Zhang]

Added code style fixes.

Signed-off-by: Helin Zhang 
---
 lib/librte_ether/rte_eth_ctrl.h | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 7088d8d..6ab16c2 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -62,8 +62,8 @@ enum rte_filter_type {
  * Generic operations on filters
  */
 enum rte_filter_op {
+   /** used to check whether the type filter is supported */
RTE_ETH_FILTER_NOP = 0,
-   /**< used to check whether the type filter is supported */
RTE_ETH_FILTER_ADD,  /**< add filter entry */
RTE_ETH_FILTER_UPDATE,   /**< update filter entry */
RTE_ETH_FILTER_DELETE,   /**< delete filter entry */
@@ -75,16 +75,15 @@ enum rte_filter_op {
RTE_ETH_FILTER_OP_MAX
 };

-/**
+/*
  * MAC filter type
  */
 enum rte_mac_filter_type {
RTE_MAC_PERFECT_MATCH = 1, /**< exact match of MAC addr. */
-   RTE_MACVLAN_PERFECT_MATCH,
-   /**< exact match of MAC addr and VLAN ID. */
+   RTE_MACVLAN_PERFECT_MATCH, /**< exact match of MAC addr and VLAN ID. */
RTE_MAC_HASH_MATCH, /**< hash match of MAC addr. */
+   /** hash match of MAC addr and exact match of VLAN ID. */
RTE_MACVLAN_HASH_MATCH,
-   /**< hash match of MAC addr and exact match of VLAN ID. */
 };

 /**
-- 
1.8.1.4

[dpdk-dev] [PATCH v8 0/4] Support configuring hash functions

[Helin Zhang]

These patches mainly support configuring hash functions. In detail,
 - It can get/set global hash configurations.
  * Get/set symmetric hash enable per flow type.
  * Get/set hash function type.
 - It can get/set symmetric hash enable per port.
 - Four commands have been implemented in testpmd to support testing above.
   * get_sym_hash_ena_per_port
   * set_sym_hash_ena_per_port
   * get_hash_global_config
   * set_hash_global_config

It also uses constant hash keys to replace runtime generating hash keys.
Global initialization is added to correctly put registers to an initial state.

v3 changes:
* Removed renamings in rte_ethdev.h.
* Redesigned filter control API and its relevant structures/enums.
* Renamed header file from rte_eth_features.h to rte_eth_ctrol.h.
* Remove public header file of rte_i40e.h specific for i40e.
* Added hardware initialization function during port init.
* Used constant random hash keys in i40e PF.
* renamed the commands in testpmd based on the redesigned filter control API.

v4 changes:
* Fixed a bug in testpmd to support 'set_sym_hash_ena_per_port'.

v5 changes:
* Integrated with filter API defined recently.
* Remove all for filter API definition, as it has already defined and merged
  recently.

v6 changes:
* Flow type strings are used to replace Packet Classification Types, to isolate
  hardware specific things.
* Implemented the mapping function to convert RSS offload types to Packet
  Classification Types, to isolate the real hardware specific things.
* Removed initialization of global registers in i40e PMD, as global registers
  shouldn't be initialized per port.
* Added more annotations to get code more understandable.
* Corrected annotation format for documenation.

v7 changes:
* Removed swap configurations, as it is not allowed by hardware design.
* Put symmetric hash per flow type and hash function type into
  'RTE_ETH_HASH_FILTER_GLOBAL_CONFIG', as they are controlling global registers
  which will affects all the ports of the same NIC.

v8 changes:
* Removed redundant checks in i40e_ethdev.c.
* Solved compile errors on ICC.

Helin Zhang (4):
  ethdev: code style fixes
  i40e: use constant as the default hash keys
  i40e: support of controlling hash functions
  app/testpmd: add commands to support hash functions

 app/test-pmd/cmdline.c| 333 ++
 lib/librte_ether/rte_eth_ctrl.h   |  72 -
 lib/librte_pmd_i40e/i40e_ethdev.c | 308 +--
 3 files changed, 699 insertions(+), 14 deletions(-)

-- 
1.8.1.4

[dpdk-dev] [PATCH v2] kni: create KNI interface in current network namespace

[Nicolas Dichtel]

Le 02/12/2014 03:19, Takayuki Usui a ?crit :
> With this patch, KNI interface (e.g. vEth0) is created in the
> network namespace where the DPDK application is running.
> Otherwise, all interfaces are created in the default namespace
> in the host.
>
> put_net() is required, since get_net_ns_by_pid() increments
> the reference counter of the network namespace with get_net().
>
> Signed-off-by: Takayuki Usui 
> ---
>   lib/librte_eal/linuxapp/kni/kni_misc.c | 7 +++
>   1 file changed, 7 insertions(+)
>
> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
> b/lib/librte_eal/linuxapp/kni/kni_misc.c
> index ba6..33c7a48 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
> @@ -311,6 +311,7 @@ kni_ioctl_create(unsigned int ioctl_num, unsigned long 
> ioctl_param)
>   struct net_device *net_dev = NULL;
>   struct net_device *lad_dev = NULL;
>   struct kni_dev *kni, *dev, *n;
> + struct net *net;
>
>   printk(KERN_INFO "KNI: Creating kni...\n");
>   /* Check the buffer size, to avoid warning */
> @@ -354,6 +355,12 @@ kni_ioctl_create(unsigned int ioctl_num, unsigned long 
> ioctl_param)
>   return -EBUSY;
>   }
>
> + net = get_net_ns_by_pid(current->pid);
> + if (IS_ERR(net))
In case of error, you should call free_netdev(net_dev) to avoid a memory leak.

> + return PTR_ERR(net);
> + dev_net_set(net_dev, net);
> + put_net(net);
> +
>   kni = netdev_priv(net_dev);
>
>   kni->net_dev = net_dev;
>

[dpdk-dev] [PATCH] add one option memory-only for those secondary PRBs

[Chi, Xiaobo (NSN - CN/Hangzhou)]

Hi, 
The similar functionality of this patch has been sent out for review on Nov.12, 
email topic is "[dpdk-dev] one lightwight rte_eal_init() for SECONDARY 
processes which only use sharedmemory".  This time, I just change the 
implementation method according to comments from Bruce Richardson. 

Background:
What we are doing now is port make telecom network element to be cloud based.  
For one of our product,  DPDK is applied not only for fastpath/dataplane 
processing, but also for Distributed Message eXchange (DMX) between different 
processes/applications which may located in different VM even different host.  
for such a DMX system, in one VM, we have one DPDK based dmxdemo (which acts as 
the PRIMARY) which is in charge of distribute message between different 
applications, and dozens of applications (act as SECONDARY) to use DPDK based 
rte_tx_ring/rte_rx_ring/mempool/memzone to send receive messages to dmxdemo.

Problem:
Here, these DPDK based SECONDARY processes need only the DPDK's hugepage based 
sharememory mechanism and it's upper libs (such as ring, mempool, etc.), they 
need not cpu core pinning, iopl privilege changing , pci device, timer, alarm, 
interrupt, shared_driver_list,  core_info, threads for each core, etc. Then, 
for such kind of SECONDARY processes, the current rte_eal_init() is too heavy.  
I have seen some others also met similar troubles. 

Solution:
One new EAL initializing argument, --memory-only, is added. It is only for 
those SECONDARY processes which only want to share memory with primary process. 
When this argument is defined, users need not define those madentory arguments, 
such as "-c xx -n xx", due to we don't want to pin such kind of processes to 
any CPUs.

I have tested on my test env, it works. Please kindly help to review and give 
comments. Thanks.

-Original Message-
From: chixiaobo [mailto:xiaobo@nsn.com] 
Sent: Tuesday, December 02, 2014 5:41 PM
To: dev at dpdk.org
Cc: Chi, Xiaobo (NSN - CN/Hangzhou)
Subject: [PATCH] add one option memory-only for those secondary PRBs

---
 lib/librte_eal/common/eal_common_options.c |  18 +++-
 lib/librte_eal/common/eal_internal_cfg.h   |   1 +
 lib/librte_eal/common/eal_options.h|   4 +-
 lib/librte_eal/linuxapp/eal/eal.c  | 137 +++--
 4 files changed, 89 insertions(+), 71 deletions(-)
 mode change 100644 => 100755 lib/librte_eal/common/eal_common_options.c
 mode change 100644 => 100755 lib/librte_eal/common/eal_internal_cfg.h
 mode change 100644 => 100755 lib/librte_eal/common/eal_options.h
 mode change 100644 => 100755 lib/librte_eal/linuxapp/eal/eal.c

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
old mode 100644
new mode 100755
index e2810ab..5ab4b87
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -85,6 +85,7 @@ eal_long_options[] = {
{OPT_XEN_DOM0, 0, 0, OPT_XEN_DOM0_NUM},
{OPT_CREATE_UIO_DEV, 1, NULL, OPT_CREATE_UIO_DEV_NUM},
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
+{OPT_MEMORY_ONLY, 0, NULL, OPT_MEMORY_ONLY_NUM},
{0, 0, 0, 0}
 };

@@ -126,6 +127,7 @@ eal_reset_internal_config(struct internal_config 
*internal_cfg)
internal_cfg->no_hpet = 1;
 #endif
internal_cfg->vmware_tsc_map = 0;
+internal_cfg->memory_only= 0;
 }

 /*
@@ -454,6 +456,10 @@ eal_parse_common_option(int opt, const char *optarg,
conf->process_type = eal_parse_proc_type(optarg);
break;

+   case OPT_MEMORY_ONLY_NUM:
+   conf->memory_only= 1;
+   break;
+
case OPT_MASTER_LCORE_NUM:
if (eal_parse_master_lcore(optarg) < 0) {
RTE_LOG(ERR, EAL, "invalid parameter for --"
@@ -525,9 +531,9 @@ eal_check_common_options(struct internal_config 
*internal_cfg)
 {
struct rte_config *cfg = rte_eal_get_configuration();

-   if (!lcores_parsed) {
-   RTE_LOG(ERR, EAL, "CPU cores must be enabled with options "
-   "-c or -l\n");
+   if (!lcores_parsed && !(internal_cfg->process_type == 
RTE_PROC_SECONDARY&& internal_cfg->memory_only) ) {
+   RTE_LOG(ERR, EAL, "For those processes without memory-only 
option, CPU cores "
+"must be enabled with options -c or -l\n");
return -1;
}
if (cfg->lcore_role[cfg->master_lcore] != ROLE_RTE) {
@@ -545,6 +551,11 @@ eal_check_common_options(struct internal_config 
*internal_cfg)
"specified\n");
return -1;
}
+   if ( internal_cfg->process_type != RTE_PROC_SECONDARY &&
+   internal_cfg->memory_only) {
+   RTE_LOG(ERR, EAL, "only secondary processes can specify 
memory-only option.\n");
+   return -1;
+   }
if (index(internal_cfg->hugefile_prefix, '%') != NULL) {
RTE_LOG(ERR, EAL, "Invalid

[dpdk-dev] virtio merging - no UIO

[Vincent JARDIN]

 From today's call, I'd like to highlight that virtio-net-pmd (said code 
B - from 6WIND) does not require UIO; it was required for some security 
reasons of the guest Linux OS:
   http://dpdk.org/browse/virtio-net-pmd/tree/virtio_user.c#n1494

Thank you,
   Vincent

[dpdk-dev] [PATCH] lpm: fix maybe-uninitialized warning when using LTO during compilation

[Bruce Richardson]

On Mon, Dec 01, 2014 at 04:39:06PM -0800, Dennis Marinus wrote:
> This patch fixes a maybe-uninitialized warning when compiling DPDK with
> GCC 4.9 + Link Time Optimization.
> 
> Signed-off-by: Dennis Marinus 

Acked-by: Bruce Richardson 

> ---
>  lib/librte_table/rte_table_lpm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_table/rte_table_lpm.c 
> b/lib/librte_table/rte_table_lpm.c
> index 59f87bb..cf92619 100644
> --- a/lib/librte_table/rte_table_lpm.c
> +++ b/lib/librte_table/rte_table_lpm.c
> @@ -185,7 +185,7 @@ rte_table_lpm_entry_add(
>   struct rte_table_lpm_key *ip_prefix = (struct rte_table_lpm_key *) key;
>   uint32_t nht_pos, nht_pos0_valid;
>   int status;
> - uint8_t nht_pos0;
> + uint8_t nht_pos0 = 0;
>  
>   /* Check input parameters */
>   if (lpm == NULL) {
> -- 
> 2.1.2.AMZN
> 

[dpdk-dev] virtio merging - no UIO

[Ouyang, Changchun]

Hi Vincent,
Thanks for your highlighting.  Will consider how to resolve it. 
regards
Changchun

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, December 2, 2014 4:23 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] virtio merging - no UIO
> 
>  From today's call, I'd like to highlight that virtio-net-pmd (said code B - 
> from
> 6WIND) does not require UIO; it was required for some security reasons of
> the guest Linux OS:
>http://dpdk.org/browse/virtio-net-pmd/tree/virtio_user.c#n1494
> 
> Thank you,
>Vincent

[dpdk-dev] [PATCH] i40e: Use one bit flag for all hardware detected RX packet errors

[Zhang, Helin]

> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Monday, December 1, 2014 5:58 PM
> To: Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org
> Cc: Cao, Waterman; Cao, Min
> Subject: Re: [PATCH] i40e: Use one bit flag for all hardware detected RX 
> packet
> errors
> 
> Hi Helin,
> 
> On 12/01/2014 02:57 AM, Zhang, Helin wrote:
> >>> #define PKT_RX_EIP_CKSUM_BAD (0ULL << 0)  /**< External IP header
> >>> checksum error. */ [Helin] Nobody complains it, so we will keep it
> >>> there, and
> >> just assign a new value to it.
> >>
> >> ok.
> >>
> >> But it would be nice to have a better definition of this flag: does
> >> external mean outer header? For instance, when you receive a
> >> Ether/IP1/UDP/vxlan/Ether/IP2/xxx, does the flag concerns IP1 or IP2?
> > 'E' means 'external', it indicates the (most) outer IP header checksum
> > error. If you don't think this name is not so clear, I can change it to
> 'PKT_RX_OUTER_IP_CHSUM_BAD'.
> > For inner IP header checksum error, it will be indicated by
> PKT_RX_IP_CKSUM_BAD.
> >
> >>
> >> If it's IP1, it's really strange compared to the current behavior
> >> (the flag PKT_RX_IP_CKSUM_BAD refers to IP1).
> 
> Ok.
> But the real sense of my question was about the behavior which seems different
> than with previous hardware. Today, if you receive the packet
> Ether/IP1/UDP/vxlan/Ether/IP2/xxx on an ixgbe, the flag
> PKT_RX_IP_CKSUM_BAD can be set if the checksum of IP1 is wrong. From your
> explanation, I understand that PKT_RX_EIP_CKSUM_BAD would be set for the
> same thing on i40e. Is it correct?
Yes, it is strange if ixgbe hardware checksum logic knows the packet is 
tunneling.
But, from another point of view, which seems the the ixgbe hardware does, if
checksum logic does not know tunneling, it may treat all others as data. This is
reasonable to report the error with PKT_RX_IP_CKSUM_BAD.

> 
> 
> >>> #define PKT_RX_OVERSIZE  (0ULL << 0)  /**< Num of desc of an RX
> pkt
> >> oversize. */
> >>> [Helin] I don't think it can be merge with other hardware errors. It
> >>> indicates the packet received needs more descriptors than hardware
> >>> allowed, and the part of packets can still be stored in the mbufs
> >>> provided. It is a good hint for users that larger size of mbuf might
> >>> be needed. If just put it as hardware error, users will lose this
> >>> information. So I
> >> prefer to keep it there, and just assign a new value to it.
> >>
> >> Again, a statistic counter would do the job which if it's just to
> >> provide a hint to the application.
> > It seems that we do not maintain a counter for packets in PMD, if I am
> > not wrong. Two ways current DPDK is using.
> > One is hardware provide registers to do that, we can read it directly when
> needed.
> > The other one is that applications or middle layer sw maintain its own 
> > statistics.
> 
> rte_eth_stats_get() gives the generic statistics For specific error stats,
> rte_eth_xstats_get() can be used from an application (the driver has to 
> provide
> the full list of statistics).
Yes, that function read all the statistics from registers directly. I think 
there might
already have the corresponding registers for it.

> 
> >> I wonder in which case this flag can happen. If you fill the ring
> >> with mbufs that are large enough compared to your ethernet network,
> >> this should not happen in normal conditions. I really don't believe
> >> that an application receiving an mbuf with this flag would stop the 
> >> driver, then
> refill the rings it with larger mbufs.
> > This is not because of it is lack of available RX descriptors. It is
> > because of a hardware requirement. FVL hardware requires that it
> > should not use more than 5 rx descriptors for receiving a single packet.
> 
> I still don't understand what the application should do when the flag is set.
> Maybe you could provide an example in l2fwd or testpmd?
For an application, if it is reported with this oversize error, it then easily 
knows that
the mbuf size might not be enough. If it is reported with just a hardware 
error, then
the application developer needs to dig into the PMD to see what happens. I 
think most
of application developers do not want to debug PMD to much, as it might not be 
their scope.

> 
> >> Last but not least: If it's really useful, should we have the same
> >> behavior on other drivers like ixgbe? I think we really need to care
> >> about not having different ways to use the different drivers.
> > I don't see the similar bit in ixgbe datasheet, but this restriction
> > could be common for some other NICs, as it is reasonable from hardware
> perspective.
> 
> In ixgbe, there are other error cases:
> - frames shorter than 64 bytes
> - oversize (frames larger than MAXFRS)
> - ... maybe others?
> 
> Should we have a flag for each situation? I think not.
The more the better, but we may need a tradeoff, as the flag bits is limited.

> 
> 
> >> To me, the only argument in favor of ke

[dpdk-dev] [PATCH] enicpmd: compilation error during inclusion of vfio.h

[Qiu, Michael]

On 11/28/2014 10:56 PM, Neil Horman wrote:
> On Fri, Nov 28, 2014 at 02:09:40AM +, Qiu, Michael wrote:
>> Hi all,
>>
>> I have no comments on this issue, but I indeed see many places do have
>> this kernel issue(before/now/future), so can solve this issue globally?
>>
>> Thus, we do not need to fix this case by case.
>>
>> One solution(not sure if it works or not):
>>
>> 1. features and kernel version required list.
>> 2. When config DPDK before build, automatically check this list and if
>> not mach, just disable this feature in config file even though user set
>> it manually.
>>
> Instead of enumerating a kernel version, this should be designed as an
> enumeration of feature sets.  That way you can enable DPDK features based on
> kernel feature availability (i.e. kernel version doesn't necessecarily imply
> feature set, like when a distribution backports a given feature to an older
> kernel.

Yes, you are right, I haven't consider about this situation before.
Actually, for kernel version based static available list, DPDK at least
could run without risk.

> What would really make the most sense I think is to convert the configuration
> system to autoconf/automake, so that these tests can be preformed at config
> time.

Agree,
Another choice is would be like the linux kernel, type 'make config' or
'make menuconfig' and post the feature list to user, this is more
friendly for cross-compile in my option.

Thanks,
Michael
> Neil
>
>> Thus main code may not need to change.
>>
>> Does this works?
>>
>> Thanks,
>> Michael
>>
>> On 11/28/2014 1:16 AM, Sujith Sankar wrote:
>>> Inclusion of vfio.h was giving compilation errors if kernel version is less
>>> than 3.6.0 and if RTE_EAL_VFIO was on in config.
>>>
>>> Replaced inclusion of vfio.h with eal_vfio.h and replaced RTE_EAL_VFIO with
>>> VFIO_PRESENT in enicpmd code.
>>>
>>> Signed-off-by: Sujith Sankar 
>>> ---
>>>  lib/librte_pmd_enic/Makefile|  1 +
>>>  lib/librte_pmd_enic/enic_main.c | 13 +
>>>  2 files changed, 6 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile
>>> index d4c2f66..befc552 100644
>>> --- a/lib/librte_pmd_enic/Makefile
>>> +++ b/lib/librte_pmd_enic/Makefile
>>> @@ -39,6 +39,7 @@ LIB = librte_pmd_enic.a
>>>  
>>>  CFLAGS += -I$(RTE_SDK)/lib/librte_hash/ 
>>> -I$(RTE_SDK)/lib/librte_pmd_enic/vnic/
>>>  CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/
>>> +CFLAGS += -I$(RTE_SDK)/lib/librte_eal/linuxapp/eal/
>>>  CFLAGS += -O3 -Wno-deprecated
>>>  
>>>  VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src
>>> diff --git a/lib/librte_pmd_enic/enic_main.c 
>>> b/lib/librte_pmd_enic/enic_main.c
>>> index 4b857bb..f6f00d3 100644
>>> --- a/lib/librte_pmd_enic/enic_main.c
>>> +++ b/lib/librte_pmd_enic/enic_main.c
>>> @@ -39,9 +39,6 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> -#ifdef RTE_EAL_VFIO
>>> -#include 
>>> -#endif
>>>  
>>>  #include 
>>>  #include 
>>> @@ -631,7 +628,7 @@ int enic_enable(struct enic *enic)
>>>  
>>> vnic_dev_enable_wait(enic->vdev);
>>>  
>>> -#ifndef RTE_EAL_VFIO
>>> +#ifndef VFIO_PRESENT
>>> /* Register and enable error interrupt */
>>> rte_intr_callback_register(&(enic->pdev->intr_handle),
>>> enic_intr_handler, (void *)enic->rte_dev);
>>> @@ -995,7 +992,7 @@ int enic_setup_finish(struct enic *enic)
>>> return 0;
>>>  }
>>>  
>>> -#ifdef RTE_EAL_VFIO
>>> +#ifdef VFIO_PRESENT
>>>  static void enic_eventfd_init(struct enic *enic)
>>>  {
>>> enic->eventfd = enic->pdev->intr_handle.fd;
>>> @@ -1033,7 +1030,7 @@ int enic_get_link_status(struct enic *enic)
>>>  }
>>>  
>>>  
>>> -#ifdef RTE_EAL_VFIO
>>> +#ifdef VFIO_PRESENT
>>>  static int enic_create_err_intr_thread(struct enic *enic)
>>>  {
>>> pthread_attr_t intr_attr;
>>> @@ -,7 +1108,7 @@ static void enic_dev_deinit(struct enic *enic)
>>> if (eth_dev->data->mac_addrs)
>>> rte_free(eth_dev->data->mac_addrs);
>>>  
>>> -#ifdef RTE_EAL_VFIO
>>> +#ifdef VFIO_PRESENT
>>> enic_clear_intr_mode(enic);
>>>  #endif
>>>  }
>>> @@ -1167,7 +1164,7 @@ static int enic_dev_init(struct enic *enic)
>>> */
>>> enic_get_res_counts(enic);
>>>  
>>> -#ifdef RTE_EAL_VFIO
>>> +#ifdef VFIO_PRESENT
>>> /* Set interrupt mode based on resource counts and system
>>>  * capabilities
>>>  */
>>

[dpdk-dev] [PATCH] enicpmd: compilation error during inclusion of vfio.h

[Qiu, Michael]

On 11/28/2014 10:22 PM, Thomas Monjalon wrote:
> 2014-11-28 02:09, Qiu, Michael:
>> I have no comments on this issue, but I indeed see many places do have
>> this kernel issue(before/now/future), so can solve this issue globally?
>>
>> Thus, we do not need to fix this case by case.
>>
>> One solution(not sure if it works or not):
>>
>> 1. features and kernel version required list.
>> 2. When config DPDK before build, automatically check this list and if
>> not mach, just disable this feature in config file even though user set
>> it manually.
>>
>> Thus main code may not need to change.
>>
>> Does this works?
> If configuration system was different, we could have a list of constraint
> to satisfy before enabling a feature.

Yes,  I thinks so.

BTW, Is this valuable to spend time on, or can become one feature?

If so, I would like to have some time to do some research on it.

Thanks,
Michael
>

[dpdk-dev] [PATCH] i40e: bug fix of compile error

[Qiu, Michael]

On 12/2/2014 8:36 AM, Zhang, Helin wrote:
>
>> -Original Message-
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> Sent: Monday, December 1, 2014 7:13 PM
>> To: Zhang, Helin
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] i40e: bug fix of compile error
>>
>> 2014-12-01 15:33, Helin Zhang:
>>> The compile error will occur as below when set
>> 'RTE_LIBRTE_I40E_16BYTE_RX_DESC=y'.
>>> The changes is just to fix it.
>>>
>>> lib/librte_pmd_i40e/i40e_rxtx.c: In function i40e_rxd_build_fdir:
>>> lib/librte_pmd_i40e/i40e_rxtx.c:431:28: error: volatile union
>>>  has no member named fd
>>> lib/librte_pmd_i40e/i40e_rxtx.c:427:19: error: unused variable flexbl
>>> [-Werror=unused-variable]
>>> lib/librte_pmd_i40e/i40e_rxtx.c:427:11: error: unused variable flexbh
>>> [-Werror=unused-variable]
>> It would be nice to reference the commit which introduced the error and 
>> explain
>> it a bit.
>>
>>> -   
>>> rte_le_to_cpu_32(rxdp->wb.qword3.hi_dword.flex_bytes_hi);
>>> +   rte_le_to_cpu_32(
>>> +   rxdp->wb.qword3.hi_dword.flex_bytes_hi);
>> [...]
>>> -   
>>> rte_le_to_cpu_32(rxdp->wb.qword3.lo_dword.flex_bytes_lo);
>>> +   rte_le_to_cpu_32(
>>> +   rxdp->wb.qword3.lo_dword.flex_bytes_lo);
>> Why are you wrapping these lines (with wrong indentation)?
>> It makes the fix confuse.
> Sorry, it is a code style fix, as the length of the line should not be more 
> than 80.
> Do I need to split the patch or add more commit logs?

I think this coding style fix is not good enough,

mb->hash.fdir.hi = rte_le_to_cpu_32(rxdp->wb.qword3
.hi_dword.fd_id);

This would be better :)

See the attached diff file, so sorry I indeed do not know how to add
diff file in the email(except git send-email), So I just attached it.

>
>> --
>> Thomas
> Regards,
> Helin
>

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: diff_code_style_fix
URL: 
<http://dpdk.org/ml/archives/dev/attachments/20141202/4ef56489/attachment.ksh>

[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors

[Neil Horman]

On Mon, Dec 01, 2014 at 10:55:29PM +0100, Olivier MATZ wrote:
> Hi Neil,
> 
> On 12/01/2014 06:16 PM, Neil Horman wrote:
> >>> [...]
> >>>
> >>> Whats the advantage to keeping this warning?
> >>>
> >> The advantage is that it does exactly what it's meant to do. If someone 
> >> goes to
> >> assign l2_len = 128; somewhere, it will throw a warning. If someone goes 
> >> to change
> >> the lpm library and set [lpm_table_entry].depth = 64 somewhere, it will 
> >> throw
> >> a warning. The reason the warning is a problem here is because we are in 
> >> the
> >> usual position of wanting to initialize all values to 1's. It's causing 
> >> problems
> >> nowhere else.
> >>
> >> However, let me query the scope of the disabling the warning you are 
> >> talking about.
> >> If we just disable the warning for the one problematic function, it's 
> >> probably
> >> reasonable enough because of the all-1's initialization, but disabling it 
> >> globally
> >> is not something I would agree with.
> >>
> > No, this actually makes some sense as far as the warning goes, though it 
> > seems
> > like we can't rely on it, since clang is the only thing that throws the 
> > warning.
> > 
> > That said, I was just looking at this code, and I think the use of these
> > bitfields is problematic anyway (or at least potentially so).  The bitfields
> > exist as a set in a union that also contains a data field, and the 
> > bitfields and
> > data are type puned (both in the ixgbe implementation and I think in the
> > rte_mbuf implementation).  GCC (nor any C compiler that I'm aware of) 
> > provides
> > any guarantee regarding the bit endianess of any given field, nor any 
> > padding in
> > between bitfields, nor any ordering among bitfields.  The take away from 
> > that
> > is, while I can't currently find any use of the data member of the 
> > referenced
> > unions, if theres any expectation as to the value of said data member of 
> > that
> > union, theres no guarantee it will be correct between platforms.  It seems 
> > like
> > we should be using a single typed integer value here and some bit shifting
> > values to set fields within it, rather than bitfields.
> 
> The padding and endianess of bitfields is maybe not defined, but I think
> many people at least suppose the way it works, since we have the
> following code in standard headers (netinet/ip.h):
> 
>   #if __BYTE_ORDER == __LITTLE_ENDIAN
> unsigned int flags:4;
> unsigned int overflow:4;
>   #elif __BYTE_ORDER == __BIG_ENDIAN
> unsigned int overflow:4;
> unsigned int flags:4;
> 
Thats true, but the Linux kernel has the luxury of assuming that gcc is the only
compiler that will be building it, and so developers are free to make
assumptions about its behavior.  Thats not true of the DPDK.  DPDK allows at
least 3 compilers to build it in a supported fashion (clan/llvm, icc and gcc).
The behavior of the above may be completely different on each compiler.

> That said, the .data field of the union is only used to do faster
> assignment and comparison in ixgbe or mbuf, so I don't think there is
> no issue with that.
> 
Thats exactly the problem I'm referring to.  If ixgbe preforms assignment on the
.data value (of anything other than all 1's or all 0's), this will break.  Its
also problematic in a larger scope because rte_mbuf uses this same pattern, and
that interface is exposed to applications, where we have no visibility over what
is being accessed and how.

> About removing the warning, I agree with Bruce: it is maybe useful in
> other cases and I think we should keep it. However, if there is no
> consensus on the "|=" solution, I can provide another patch that solves
> the issue in a different way, maybe using a static const variable.
> 
> Regards,
> Olivier
> 

[dpdk-dev] [PATCH v2] i40e: link flow control support

[Cao, Min]

Tested-by: Min Cao 

Patch name: [dpdk-dev] [PATCH v2] i40e: link flow control support
Test Flag:  Tested-by
Tester name:min.cao at intel.com
Result summary: total 4 cases, 4 passed, 0 failed

Test Case 1:
Name:   flowctrl_off_pause_fwd_off
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle/spirit 
Test result:PASSED

Test Case 2:
Name:   flowctrl_on_pause_fwd_off
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle/spirit 
Test result:PASSED

Test Case 3:
Name:   flowctrl_off_pause_fwd_on
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle/spirit 
Test result:PASSED

Test Case 4:
Name:   flowctrl_on_pause_fwd_on
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle/spirit 
Test result:PASSED
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of zhida zang
Sent: Thursday, November 20, 2014 4:59 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v2] i40e: link flow control support

From: zzang 

Add link flow control support for i40e

Signed-off-by: zhida zang 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 155 +-
 lib/librte_pmd_i40e/i40e_ethdev.h |  10 +++
 2 files changed, 162 insertions(+), 3 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index a860af7..183b0be 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -69,6 +69,18 @@
 #define I40E_DEFAULT_TX_WTHRESH  0
 #define I40E_DEFAULT_TX_RSBIT_THRESH 32

+/* Flow control default timer */
+#define I40E_DEFAULT_PAUSE_TIME 0xU
+
+/* Flow control default high water */
+#define I40E_DEFAULT_HIGH_WATER 0x1C40
+
+/* Flow control default low water */
+#define I40E_DEFAULT_LOW_WATER  0x1A40
+
+/* Flow control enable fwd bit */
+#define I40E_PRTMAC_FWD_CTRL   0x0001
+
 /* Maximun number of MAC addresses */
 #define I40E_NUM_MACADDR_MAX   64
 #define I40E_CLEAR_PXE_WAIT_MS 200
@@ -98,6 +110,12 @@

 #define I40E_PRE_TX_Q_CFG_WAIT_US   10 /* 10 us */

+/* Receive Packet Buffer size */
+#define I40E_RXPBSIZE (968 * 1024)
+
+/* Receive Average Packet Size in Byte*/
+#define I40E_PACKET_AVERAGE_SIZE 128
+
 static int eth_i40e_dev_init(\
__attribute__((unused)) struct eth_driver *eth_drv,
struct rte_eth_dev *eth_dev);
@@ -131,6 +149,8 @@ static void i40e_vlan_strip_queue_set(struct rte_eth_dev 
*dev,
 static int i40e_vlan_pvid_set(struct rte_eth_dev *dev, uint16_t pvid, int on);
 static int i40e_dev_led_on(struct rte_eth_dev *dev);
 static int i40e_dev_led_off(struct rte_eth_dev *dev);
+static int i40e_flow_ctrl_get(struct rte_eth_dev *dev,
+ struct rte_eth_fc_conf *fc_conf);
 static int i40e_flow_ctrl_set(struct rte_eth_dev *dev,
  struct rte_eth_fc_conf *fc_conf);
 static int i40e_priority_flow_ctrl_set(struct rte_eth_dev *dev,
@@ -237,6 +257,7 @@ static struct eth_dev_ops i40e_eth_dev_ops = {
.tx_queue_release = i40e_dev_tx_queue_release,
.dev_led_on   = i40e_dev_led_on,
.dev_led_off  = i40e_dev_led_off,
+   .flow_ctrl_get= i40e_flow_ctrl_get,
.flow_ctrl_set= i40e_flow_ctrl_set,
.priority_flow_ctrl_set   = i40e_priority_flow_ctrl_set,
.mac_addr_add = i40e_macaddr_add,
@@ -358,6 +379,9 @@ eth_i40e_dev_init(__rte_unused struct eth_driver *eth_drv,
pf->adapter = I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
pf->adapter->eth_dev = dev;
pf->dev_data = dev->data;
+   pf->fc_conf.pause_time = I40E_DEFAULT_PAUSE_TIME;
+   pf->fc_conf.high_water[0] = I40E_DEFAULT_HIGH_WATER;
+   pf->fc_conf.low_water[0] = I40E_DEFAULT_LOW_WATER;

hw->back = I40E_PF_TO_ADAPTER(pf);
hw->hw_addr = (uint8_t *)(pci_dev->mem_resource[0].addr);
@@ -1516,12 +1540,137 @@ i40e_dev_led_off(struct rte_eth_dev *dev)
 }

 static int
-i40e_flow_ctrl_set(__rte_unused struct rte_eth_dev *dev,
-  

[dpdk-dev] [PATCH] i40e: bug fix of compile error

[Zhang, Helin]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, December 1, 2014 7:13 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] i40e: bug fix of compile error
> 
> 2014-12-01 15:33, Helin Zhang:
> > The compile error will occur as below when set
> 'RTE_LIBRTE_I40E_16BYTE_RX_DESC=y'.
> > The changes is just to fix it.
> >
> > lib/librte_pmd_i40e/i40e_rxtx.c: In function i40e_rxd_build_fdir:
> > lib/librte_pmd_i40e/i40e_rxtx.c:431:28: error: volatile union
> >  has no member named fd
> > lib/librte_pmd_i40e/i40e_rxtx.c:427:19: error: unused variable flexbl
> > [-Werror=unused-variable]
> > lib/librte_pmd_i40e/i40e_rxtx.c:427:11: error: unused variable flexbh
> > [-Werror=unused-variable]
> 
> It would be nice to reference the commit which introduced the error and 
> explain
> it a bit.
> 
> > -   
> > rte_le_to_cpu_32(rxdp->wb.qword3.hi_dword.flex_bytes_hi);
> > +   rte_le_to_cpu_32(
> > +   rxdp->wb.qword3.hi_dword.flex_bytes_hi);
> [...]
> > -   
> > rte_le_to_cpu_32(rxdp->wb.qword3.lo_dword.flex_bytes_lo);
> > +   rte_le_to_cpu_32(
> > +   rxdp->wb.qword3.lo_dword.flex_bytes_lo);
> 
> Why are you wrapping these lines (with wrong indentation)?
> It makes the fix confuse.
Sorry, it is a code style fix, as the length of the line should not be more 
than 80.
Do I need to split the patch or add more commit logs?

> 
> --
> Thomas

Regards,
Helin