[dpdk-dev] [PATCH v3 0/4] i40e VXLAN TX checksum rework

Jijiang Liu jijiang.liu at intel.com
Thu Nov 27 18:03:17 CET 2014

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 engine.
The main changes in mbuf are as follows,
In place of removing PKT_TX_VXLAN_CKSUM, we introducing 3 new flags: PKT_TX_OUTER_IP_CKSUM,PKT_TX_OUTER_IPV6 and PKT_TX_UDP_TUNNEL_PKT, and a new field: l4_tun_len.
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 =  eth_hdr_in;
     mb->l3_len = ipv4_hdr_in;
     mb->outer_l2_len = eth_hdr_out;
     mb->outer_l3_len = ipv4_hdr_out;
     mb->l4tun_len = vxlan_hdr;

   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.
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.
Now, B.2 is exactly what Oliver suggested.
I think it has few important advantages over B.1:
First of all - compatibility. It works across all HW we currently support (i40e/ixgbe/igb/em).
Second - it is probably faster even on FVL, as for it we have to fill only TXD, while with approach #2 we have to fill both TCD and TXD.
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 =  eth_hdr_in;
     mb->l3_len = ipv4_hdr_in;
     mb->outer_l2_len = eth_hdr_out;
     mb->outer_l3_len = ipv4_hdr_out;
     mb->l4tun_len = vxlan_hdr;

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 
Jijiang Liu (4):
  mbuf change for 3 new flags and 3 fields
  mbuf change for PKT_TX_IPV4 and PKT_TX_IPV6
  i40e PMD change in i40e_rxtx.c
  rework csum forward engine

 app/test-pmd/csumonly.c         |   65 ++++++++++++++++++++++-----------------
 lib/librte_mbuf/rte_mbuf.c      |    6 +++-
 lib/librte_mbuf/rte_mbuf.h      |   22 ++++++++-----
 lib/librte_pmd_i40e/i40e_rxtx.c |   49 ++++++++++++++++-------------
 4 files changed, 82 insertions(+), 60 deletions(-)


More information about the dev mailing list