DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier MATZ <olivier.matz@6wind.com>
To: "Liu, Jijiang" <jijiang.liu@intel.com>,
	 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine
Date: Mon, 12 Jan 2015 12:43:22 +0100	[thread overview]
Message-ID: <54B3B35A.5030803@6wind.com> (raw)
In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com>

Hi Jijiang,

Please find some comments below.

On 01/12/2015 04:41 AM, Liu, Jijiang wrote:
> There are some examples for the different packet types:
> 
> 1. For L2 Packet types:
> MAC, ARP
> MAC, PAY2
> ...
> They are forwarded without beeing modified no matter if these above commands are set.

ok

>  2. For Non Tunneled IPv4/6 packet
> MAC, IPV4, UDP, PAY4
> MAC, IPV6, UDP, PAY4
> ...
> Ipv4:
> tx_checksum set  ip   hw
> tx_checksum set  udp   hw
> 
> IPv6:
> tx_checksum set  udp   hw
> 
> They are forwarded with TX checksum offload if these above commands are set.

Two questions here:

- today, we also have the "sw" argument that allows to calculate the
  checksum in software. Do you plan to keep this behavior?

- today, the csumonly forward engine modifies the IP addresses to
  validate that it is able to recalculate the checksum. Do you plan
  to keep this behavior? I'm not opposed to remove it if it makes
  the code more complex.

> 3. For Tunneled IPv4/6 packet
> 
> See the above test cases:
> Test case A
> test case B.1
> test case B.2
> test case C
> 
> They are forwarded with TX checksum offload if these above commands are set.
> 
>> I think that the test-pmd command API should define a behavior for the csum
>> forward engine for any packet. What do you think?
> 
> Agree.
> 
> Let me explain the checksum offload behavior of different packet type below,
> 
> 1. For L2 Packet types:
> Checksum offload behavior definition:
> tx_checksum set sw-tunnel-mode on :               NONE
> tx_checksum set hw-tunnel-mode on:               NONE
> tx_checksum set  outer-ip|ip|tcp|udp|sctp   hw:     NONE
> 
> 2. For Non Tunneled IPv4/6 packet
> 
> Checksum offload behavior definition:
> 
> tx_checksum set sw-tunnel-mode on :                NONE
> tx_checksum set hw-tunnel-mode on:                 NONE      
> tx_checksum set  outer-ip|ip|tcp|udp|sctp   hw:     ip|tcp|udp|sctp options   are VALID
> 
> 3. For Tunneled IPv4/6 packet
> Checksum offload behavior definition:
> 
> tx_checksum set sw-tunnel-mode on :                VALID
> tx_checksum set hw-tunnel-mode on:                 VALID 
> tx_checksum set  outer-ip|ip|tcp|udp|sctp   hw:     VALID
> 
> It is very welcome if you have better solution that is able to cover all the case in the http://dpdk.org/ml/archives/dev/2014-December/009213.html  and all packet types in csum fwd engine.

Thank you for your efforts to explain your proposition. I still have
some difficulties to understand the naming "sw-tunnel" and "hw-tunnel".
>From the user point of view "sw" means "software" and "hw" means
"hardware". I think it's difficult to understand how both can be on
at the same time. Maybe it's just a naming problem?

Also, is it still possible to compute the checksum in software?

And will it be possible to support future hardware that will be able
to compute both outer l3, outer l4, l3 and l4 checksums?


I have another idea, please let me know if you find it clearer or not.
The commands format would be:

tx_checksum <pkt-type> <field1> <action1> <field2> <action2> ...

List of commands:

# select behavior for non tunnel packets
tx_checksum ip-udp l3 off|sw|hw l4 off|sw|hw
tx_checksum ip-tcp l3 off|sw|hw l4 off|sw|hw
tx_checksum ip-sctp l3 off|sw|hw l4 off|sw|hw
tx_checksum ip-other l3 off|sw|hw

# select behavior for vxlan packets
tx_checksum vxlan outer-l3 off|sw|hw outer-l4 off|sw|hw
tx_checksum vxlan-ip-udp l3 off|sw|hw l4 off|sw|hw
tx_checksum vxlan-ip-tcp l3 off|sw|hw l4 off|sw|hw
tx_checksum vxlan-ip-sctp l3 off|sw|hw l4 off|sw|hw
tx_checksum vxlan-ip-other l3 off|sw|hw

Examples:

1. calculate l3 and l4 checksum of ip/udp packets in hw, and ip/tcp
   packets in sw. Do nothing for the other packet types

# assume all is off by default
tx_checksum ip-udp l3 hw l4 hw
tx_checksum ip-tcp l3 sw l4 sw

2. calculate outer checksums of tunnel packets (your case A.)

# assume all is off by default
tx_checksum vxlan outer-l3 hw outer-l4 hw

3. calculate inner checksums of tunnel packets (your case B.1)

# assume all is off by default
tx_checksum vxlan-ip-udp l3 hw l4 hw
tx_checksum vxlan-ip-tcp l3 hw l4 hw
tx_checksum vxlan-ip-sctp l3 hw l4 hw

4. calculate all checksums of tunnel packets (your case C)

# assume all is off by default
tx_checksum vxlan outer-l3 hw outer-l4 hw
tx_checksum vxlan-ip-udp l3 hw l4 hw
tx_checksum vxlan-ip-tcp l3 hw l4 hw
tx_checksum vxlan-ip-sctp l3 hw l4 hw


Advantages:

- clearer from use point of view: the user knows what is done for
  each packet type

- software checksum is supported for comparison with hw

- the syntax already supports future hw that can do outer l3, outer l4,
  l3 and l4 at the same time.

- we can add future tunnel packets in the same model:

  tx_checksum gre outer-l3 off|sw|hw
  tx_checksum gre-ip-udp l3 off|sw|hw l4 off|sw|hw

Cons:

- with the definition above, we cannot do B.2. But if we really want
  it, we could change the commands:

  tx_checksum xxx l3 off|sw|hw|outer-hw l4 off|sw|hw|outer-hw

  "outer-hw" means: use the outer mbuf flags to do the checksum
  It could be replaced in all commands

- this commands may lead to impossible configurations, but it can be
  checked by testpmd and a warning can be displayed.


What do you think?

Regards,
Olivier

  reply	other threads:[~2015-01-12 11:43 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10  1:03 Jijiang Liu
2014-12-10  1:03 ` [dpdk-dev] [PATCH v3 1/3] librte_ether:add outer IP offload capability flag Jijiang Liu
2014-12-11 10:33   ` Olivier MATZ
2014-12-10  1:03 ` [dpdk-dev] [PATCH v3 2/3] i40e:support outer IPv4 checksum capability Jijiang Liu
2014-12-11 10:34   ` Olivier MATZ
2014-12-10  1:03 ` [dpdk-dev] [PATCH v3 3/3] app/testpmd:change tx_checksum command and csum forwarding engine Jijiang Liu
2014-12-11 10:52   ` Olivier MATZ
2014-12-12  4:06     ` Liu, Jijiang
2014-12-11 10:17 ` [dpdk-dev] [PATCH v3 0/3] enhance TX checksum " Olivier MATZ
2014-12-12  3:48   ` Liu, Jijiang
2014-12-12 16:33     ` Olivier MATZ
2015-01-07  2:03       ` Liu, Jijiang
2015-01-07  9:59         ` Ananyev, Konstantin
2015-01-07 11:39           ` Liu, Jijiang
2015-01-07 12:07             ` Ananyev, Konstantin
2015-01-08  8:51               ` Liu, Jijiang
2015-01-08 10:54                 ` Ananyev, Konstantin
2015-01-09 10:45                   ` Olivier MATZ
2015-01-12  3:41                     ` Liu, Jijiang
2015-01-12 11:43                       ` Olivier MATZ [this message]
2015-01-13  3:04                         ` Liu, Jijiang
2015-01-13  9:55                           ` Olivier MATZ
2015-01-14  3:01                             ` Liu, Jijiang
2015-01-15 13:31                               ` Ananyev, Konstantin
2015-01-16 17:27                                 ` Olivier MATZ
2015-01-19 13:04                                   ` Ananyev, Konstantin
2015-01-19 14:38                                     ` Olivier MATZ
2015-01-20  1:12                                       ` Ananyev, Konstantin
2015-01-20 12:39                                         ` Olivier MATZ
2015-01-20 15:18                                           ` Thomas Monjalon
2015-01-20 17:10                                             ` Stephen Hemminger
2015-01-20 17:23                                           ` Ananyev, Konstantin
2015-01-20 18:15                                             ` Olivier MATZ
2015-01-21  3:12                                               ` Liu, Jijiang
2015-01-21 15:25                                                 ` Olivier MATZ
2015-01-21 16:28                                                   ` Ananyev, Konstantin
2015-01-21 17:13                                                     ` Olivier MATZ
2015-01-26  4:13                                                   ` Ananyev, Konstantin
2015-01-26  6:02                                                     ` Liu, Jijiang
2015-01-26 14:07                                                       ` Olivier MATZ
2015-01-26 14:15                                                         ` Ananyev, Konstantin
2015-01-27  8:34                                                           ` Olivier MATZ
2015-01-27 15:26                                                             ` Ananyev, Konstantin
2015-01-21 19:44                                                 ` Stephen Hemminger
2015-01-22  1:40                                                   ` Liu, Jijiang
2015-01-21  8:01                                               ` Liu, Jijiang
2015-01-21  9:10                                                 ` Olivier MATZ
2015-01-21 11:52                                                   ` Ananyev, Konstantin
2015-01-07 13:06 ` Qiu, Michael

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=54B3B35A.5030803@6wind.com \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=jijiang.liu@intel.com \
    --cc=konstantin.ananyev@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).