DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Liu, Jijiang" <jijiang.liu@intel.com>
To: Olivier MATZ <olivier.matz@6wind.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 03:41:42 +0000
Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <54AFB13E.2080200@6wind.com>

Hi,

> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Friday, January 9, 2015 6:45 PM
> To: Ananyev, Konstantin; Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and
> csum forwarding engine
> 
> Hi,
> 
> Thank you Jijiang for taking the time to get back on this.
> 
> On 01/08/2015 11:54 AM, Ananyev, Konstantin wrote:
> >> And we are able to test all of cases in
> >> http://dpdk.org/ml/archives/dev/2014-December/009213.html
> >>
> >> Test case A:
> >>
> >> tx_checksum set sw-tunnel-mode off
> >> tx_checksum set hw-tunnel-mode off
> >> tx_checksum set  ip   hw
> >>
> >> test case B.1:
> >>
> >> tx_checksum set sw-tunnel-mode on
> >> tx_checksum set hw-tunnel-mode on
> >> tx_checksum set  ip   hw
> >> tx_checksum set  tcp   hw
> >>
> >> test case B.2:
> >>
> >> tx_checksum set sw-tunnel-mode on
> >> tx_checksum set hw-tunnel-mode off
> >> tx_checksum set  ip   hw
> >>
> >> test case C:
> >>
> >> tx_checksum set sw-tunnel-mode on
> >> tx_checksum set hw-tunnel-mode on
> >> tx_checksum set  outer-ip   hw
> >> tx_checksum set  ip   hw
> >> tx_checksum set  tcp   hw
> 
> There is something I don't understand. A forward engine takes any packet in input
> and output. Packets can be of any kind (eth/arp, eth/ip/tcp,
> eth/vlan/ip/udp/vxlan/eth/ip/tcp, ...)
Yes.

> Today, the behavior of csum forward engine is defined for any kind of packet. See
> the description and the table in http://dpdk.org/ml/archives/dev/2014-
> December/009886.html
> 
> All packets that are not "Ether[/vlan]/(IP|IP6)/(UDP|TCP|SCTP)" or
> "Ether[/vlan]/(IP|IP6)/UDP/VxLAN/Ether[/vlan]/(IP|IP6)/UDP|TCP|SCTP"
> are forwarded without beeing modified.
Yes

> In my understanding, the use-case you are describing correspond to specific
> packet types. So a configuration would work only for one packet format only. Is it
> correct?

The use-cases I described correspond to all tunneling packet type, not just for "Ether[/vlan]/(IP|IP6)/UDP/VxLAN/Ether[/vlan]/(IP|IP6)/UDP|TCP|SCTP"  packet format.
Our goal is to have TX checksum framework that can cover all the case in the http://dpdk.org/ml/archives/dev/2014-December/009213.html  and all packet types in csum fwd engine.
If so, it is easy to support other tunneling type in csum fwd engine in the future. 

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.

 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.

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.

> 
> Regards,
> Olivier

  reply	other threads:[~2015-01-12  3:41 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 [this message]
2015-01-12 11:43                       ` Olivier MATZ
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=1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com \
    --to=jijiang.liu@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=olivier.matz@6wind.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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git