From: Jijiang Liu <jijiang.liu@intel.com>
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH v5 0/3] i40e VXLAN TX checksum rework
Date: Tue, 2 Dec 2014 23:06:04 +0800 [thread overview]
Message-ID: <1417532767-1309-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 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
next reply other threads:[~2014-12-02 15:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 15:06 Jijiang Liu [this message]
2014-12-02 15:06 ` [dpdk-dev] [PATCH v5 1/3] mbuf:redefine three TX ol_flags Jijiang Liu
2014-12-03 11:35 ` Olivier MATZ
2014-12-02 15:06 ` [dpdk-dev] [PATCH v5 2/3] mbuf:add three TX ol_flags and repalce PKT_TX_VXLAN_CKSUM Jijiang Liu
2014-12-03 11:41 ` Olivier MATZ
2014-12-03 12:59 ` Ananyev, Konstantin
2014-12-03 14:41 ` Olivier MATZ
2014-12-04 2:08 ` Liu, Jijiang
2014-12-04 10:23 ` Ananyev, Konstantin
2014-12-04 10:45 ` Thomas Monjalon
2014-12-04 11:03 ` Ananyev, Konstantin
2014-12-04 13:51 ` Olivier MATZ
2014-12-04 22:56 ` Ananyev, Konstantin
2014-12-05 4:17 ` Liu, Jijiang
2014-12-04 6:52 ` Zhang, Helin
2014-12-04 7:52 ` Liu, Jijiang
2014-12-04 10:19 ` Ananyev, Konstantin
2014-12-04 13:47 ` Olivier MATZ
2014-12-04 21:42 ` Ananyev, Konstantin
2014-12-05 1:15 ` Zhang, Helin
2014-12-05 11:11 ` Olivier MATZ
2014-12-02 15:06 ` [dpdk-dev] [PATCH v5 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields Jijiang Liu
2014-12-03 11:45 ` Olivier MATZ
2014-12-05 11:12 ` Olivier MATZ
2014-12-02 15:40 ` [dpdk-dev] [PATCH v5 0/3] i40e VXLAN TX checksum rework Ananyev, Konstantin
2014-12-05 16:07 ` Thomas Monjalon
2014-12-07 11:46 ` 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=1417532767-1309-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).