From: Jijiang Liu <jijiang.liu@intel.com>
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH 0/3] i40e VXLAN TX checksum rework
Date: Thu, 27 Nov 2014 16:18:36 +0800 [thread overview]
Message-ID: <1417076319-629-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 2 new flags: PKT_TX_OUT_IP_CKSUM, 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.
The existing flags are listed below,
PKT_TX_IP_CKSUM: HW IPv4 checksum for non-tunnelling packet/ HW inner IPv4 checksum for tunnelling packet
PKT_TX_TCP_CKSUM: HW TCP checksum for non-tunnelling packet/ HW inner TCP checksum for tunnelling packet
PKT_TX_SCTP_CKSUM: HW SCTP checksum for non-tunnelling packet/ HW inner SCTP checksum for tunnelling packet
PKT_TX_UDP_CKSUM: HW SCTP checksum for non-tunnelling packet/ HW inner SCTP checksum for tunnelling packet
PKT_TX_IPV4: IPv4 with no HW checksum offload for non-tunnelling packet/inner IPv4 with no HW checksum offload for tunnelling packet
PKT_TX_IPV6: IPv6 non-tunnelling packet/ inner IPv6 with no HW checksum offload for tunnelling packet
let's use a few examples to demonstrate how to use these flags:
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;
Jijiang Liu (3):
mbuf change
i40e PMD change in i40e_rxtx.c
rework csum forward engine
app/test-pmd/csumonly.c | 55 +++++++++++++++++++++-----------------
lib/librte_mbuf/rte_mbuf.c | 2 +-
lib/librte_mbuf/rte_mbuf.h | 23 ++++++++++------
lib/librte_pmd_i40e/i40e_rxtx.c | 40 ++++++++++++---------------
4 files changed, 63 insertions(+), 57 deletions(-)
--
1.7.7.6
next reply other threads:[~2014-11-27 8:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 8:18 Jijiang Liu [this message]
2014-11-27 8:18 ` [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields Jijiang Liu
2014-11-27 10:00 ` Olivier MATZ
2014-11-27 13:14 ` Liu, Jijiang
2014-11-28 9:17 ` Olivier MATZ
[not found] ` <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9EEA0@SHSMSX101.ccr.corp.intel.com>
2014-11-27 14:56 ` Ananyev, Konstantin
2014-11-27 17:01 ` Ananyev, Konstantin
2014-11-28 10:45 ` Olivier MATZ
2014-11-28 11:16 ` Ananyev, Konstantin
2014-11-30 14:50 ` Ananyev, Konstantin
2014-12-01 2:30 ` Liu, Jijiang
2014-12-01 9:52 ` Olivier MATZ
2014-12-01 11:58 ` Ananyev, Konstantin
2014-12-01 12:28 ` Olivier MATZ
2014-12-01 13:07 ` Liu, Jijiang
2014-12-01 14:31 ` Ananyev, Konstantin
2014-11-27 8:18 ` [dpdk-dev] [PATCH 2/3] i40e:PMD change for VXLAN TX checksum Jijiang Liu
2014-11-27 8:18 ` [dpdk-dev] [PATCH 3/3] testpmd:rework csum forward engine Jijiang Liu
2014-11-27 10:23 ` Olivier MATZ
2014-11-27 8:50 ` [dpdk-dev] [PATCH 0/3] i40e VXLAN TX checksum rework Liu, Jijiang
2014-11-27 9:44 ` Olivier MATZ
2014-11-27 10:12 ` Olivier MATZ
2014-11-27 12:06 ` Liu, Jijiang
2014-11-27 12:07 ` Liu, Jijiang
2014-11-27 15:29 ` Ananyev, Konstantin
2014-11-27 16:31 ` Liu, Jijiang
2014-12-03 8:02 ` Liu, Jijiang
2014-11-28 9:26 ` Olivier MATZ
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=1417076319-629-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).