DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jijiang Liu <jijiang.liu@intel.com>
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH v3 0/4] i40e VXLAN TX checksum rework
Date: Fri, 28 Nov 2014 01:03:17 +0800	[thread overview]
Message-ID: <1417107801-9544-1-git-send-email-jijiang.liu@intel.com> (raw)

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;
     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.
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;
     mb->ol_flags |= PKT_TX_OUT_IP_CKSUM  | PKT_TX_UDP_TUNNEL | PKT_TX_IP_CKSUM |  PKT_TX_TCP_CKSUM;

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(-)

-- 
1.7.7.6

             reply	other threads:[~2014-11-27 17:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-27 17:03 Jijiang Liu [this message]
2014-11-27 17:03 ` [dpdk-dev] [PATCH v3 1/4] mbuf:add three TX offload flags and change three fields Jijiang Liu
2014-11-28  9:36   ` Olivier MATZ
2014-11-28 10:27     ` Ananyev, Konstantin
2014-11-28 10:33     ` Liu, Jijiang
2014-11-28 10:40       ` Ananyev, Konstantin
2014-11-28 11:00         ` Olivier MATZ
2014-11-28 11:13           ` Ananyev, Konstantin
2014-11-28 11:18             ` Olivier MATZ
2014-11-28 15:46               ` Ananyev, Konstantin
2014-11-27 17:03 ` [dpdk-dev] [PATCH v3 2/4] mbuf:change PKT_TX_IPV4 and PKT_TX_IPV6 definition Jijiang Liu
2014-11-28  9:37   ` Olivier MATZ
2014-11-27 17:03 ` [dpdk-dev] [PATCH v3 3/4] i40e:PMD change for VXLAN TX checksum Jijiang Liu
2014-11-27 17:03 ` [dpdk-dev] [PATCH v3 4/4] testpmd:rework csum forward engine Jijiang Liu
2014-11-28  9:50   ` Olivier MATZ
2014-11-28 10:10     ` Thomas Monjalon
2014-11-27 17:24 ` [dpdk-dev] [PATCH v3 0/4] i40e VXLAN TX checksum rework Ananyev, Konstantin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1417107801-9544-1-git-send-email-jijiang.liu@intel.com \
    --to=jijiang.liu@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).