[dpdk-dev] [PATCH v3] i40e: fix TSO issue for tx function

[Zhe Tao <zhe.tao@intel.com>]

Issue:

when using the following CLI in testpmd to enable ipv6 TSO feature
(set --txqflags=0 in the testpmd command)
	set verbose 1
	csum set ip hw 0
	csum set udp hw 0
	csum set tcp hw 0
	csum set sctp hw 0
	csum set outer-ip hw 0
	csum parse_tunnel on 0
	tso set 800 0
	set fwd csum
	start

We will not get what we want, the ipv6 packets sent out from IXIA can be 
received by i40e, but cannot forward to another port.
The root cause is when HW doing the TSO offload for packets, it does not only
depends on the context descriptor to define the MSS and TSO payload size, it
also need to know whether this packets is ipv4 or ipv6, we use 
i40e_txd_enable_checksum to generate the related fields for data descriptor.
But PMD will not call i40e_txd_enable_checksum if only the TSO offload flag is
set. The reason why ipv4 works fine for TSO in testpmd csum mode is csum engine
will set the ip csum flag when the packet is ipv4 and TSO is enabled but 
will not set the flag for ipv6 and this flag will cause the
i40e_txd_enable_checksum to be invoked. For both the cases the TSO flag will be
set, so we need to use TSO flag to trigger the i40e_txd_enable_checksum.
The right logic here is we enable csum offload for both ipv4 and ipv6 when TSO
flag is set.
 
Fixes: e3f0151f (i40e: enable Tx checksum only for offloaded packets)
---
 drivers/net/i40e/i40e_rxtx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 81cde6c..6e3fd25 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -76,6 +76,7 @@
 #define I40E_TX_CKSUM_OFFLOAD_MASK (		 \
 		PKT_TX_IP_CKSUM |		 \
 		PKT_TX_L4_MASK |		 \
+		PKT_TX_TCP_SEG |		 \
 		PKT_TX_OUTER_IP_CKSUM)
 
 static uint16_t i40e_xmit_pkts_simple(void *tx_queue,
-- 
v2: changed condition check for ipv6 TSO checksum offload
    use a more clear check method which include both ipv4 & ipv6 TSO
v3: edited the commit log and title because this problem exists for both
    ipv4 and ipv6
2.1.4