From: Olivier MATZ <olivier.matz@6wind.com>
To: Jijiang Liu <jijiang.liu@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v5 3/3] mbuf:replace the inner_l2_len and the inner_l3_len fields
Date: Wed, 03 Dec 2014 12:45:21 +0100 [thread overview]
Message-ID: <547EF7D1.40505@6wind.com> (raw)
In-Reply-To: <1417532767-1309-4-git-send-email-jijiang.liu@intel.com>
Hi Jijiang,
On 12/02/2014 04:06 PM, Jijiang Liu wrote:
> 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.
>
> Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
> ---
> app/test-pmd/csumonly.c | 58 +++++++++++++++++++++------------------
> lib/librte_mbuf/rte_mbuf.h | 4 +-
> lib/librte_pmd_i40e/i40e_rxtx.c | 38 +++++++++++++------------
> 3 files changed, 53 insertions(+), 47 deletions(-)
>
One more thing about the arguments of testpmd, thay may be changed
a bit to make it clearer. We may also remove the distinction between
udp/tcp/sctp and just have l4 instead.
We don't need to add a tunnel-type argument in the testpmd
command line, because the application is already able to parse
the packet and can set the proper tunnel flag by itself.
This is the current description of the csumonly forward engine:
* Receive a burst of packets, and for each packet:
* - parse packet, and try to recognize a supported packet type (1)
* - if it's not a supported packet type, don't touch the packet, else:
* - modify the IPs in inner headers and in outer headers if any
* - reprocess the checksum of all supported layers. This is done in SW
* or HW, depending on testpmd command line configuration
* - if TSO is enabled in testpmd command line, also flag the mbuf for
* TCP segmentation offload (this implies HW TCP checksum)
* Then transmit packets on the output port.
*
* (1) Supported packets are:
* Ether / (vlan) / IP|IP6 / UDP|TCP|SCTP .
* Ether / (vlan) / outer IP|IP6 / outer UDP / VxLAN / Ether / IP|IP6
* / UDP|TCP|SCTP
*
* The testpmd command line for this forward engine sets the flags
* TESTPMD_TX_OFFLOAD_* in ports[tx_port].tx_ol_flags. They control
* wether a checksum must be calculated in software or in hardware. The
* IP, UDP, TCP and SCTP flags always concern the inner layer. The
* VxLAN flag concerns the outer IP and UDP layer (if packet is
* recognized as a vxlan packet).
This would give:
tx_cksum set (outer-ip|outer-l4|ip|l4) (hw|sw) (port_id)
A/ outer-ip=sw, outer-l4=sw, ip=sw, l4=sw
Ether / IP / UDP
IP, UDP checksum reprocessed in sw
Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
IP1, UDP1, IP2, UDP2 checksums reprocessed in sw
B/ outer-ip=hw, outer-l4=hw, ip=sw, l4=sw
Ether / IP / UDP
IP, UDP checksum reprocessed in sw
Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
IP1, UDP1 checksums reprocessed in hw (using l2_len, l3_len)
IP2, UDP2 checksums reprocessed in sw
C/ outer-ip=hw, outer-l4=hw, ip=hw, l4=hw
Ether / IP / UDP
IP, UDP checksum reprocessed in hw (using l2_len, l3_len)
Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
IP1 checksums reprocessed in hw (using outer_l2_len, outer_l3_len)
UDP1 checksum must be 0 in packet (I think it's not supported by hw
or driver today)
IP2, UDP2 checksums reprocessed in hw (using l2_len, l3_len)
D/ outer-ip=sw, outer-l4=sw, ip=hw, l4=hw
Ether / IP / UDP
IP, UDP checksum reprocessed in hw (using l2_len and l3_len)
Ether / IP1 / UDP1 / VxLAN / Ether / IP2 / UDP2:
not supported, we are not able to calculate the outer
checksum in sw as some inner fields will be filled by the hw
What is your opinion?
Regards,
Olivier
next prev parent reply other threads:[~2014-12-03 11:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 15:06 [dpdk-dev] [PATCH v5 0/3] i40e VXLAN TX checksum rework Jijiang Liu
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 [this message]
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=547EF7D1.40505@6wind.com \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=jijiang.liu@intel.com \
/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).