DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Liu, Jijiang" <jijiang.liu@intel.com>
To: Olivier MATZ <olivier.matz@6wind.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: Tue, 13 Jan 2015 03:04:08 +0000	[thread overview]
Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA8E36@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <54B3B35A.5030803@6wind.com>

Hi,

> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Monday, January 12, 2015 7:43 PM
> To: Liu, Jijiang; Ananyev, Konstantin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and
> csum forwarding engine
> 
> 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?

Yes

> - 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? 
Yes

> 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".


Again,  I'd like to explain what behaviors  the following two commands are.

1. tx_checksum set sw-tunnel-mode on/off

2. tx_checksum set hw-tunnel-mode on/off

For command 1, If the sw-tunnel-mode is set/clear, which will set/clear a testpmd flag that is used in the process of analyzing incoming packet., the pseudo-codes are list below,

If (sw-tunnel-mode) 

	Csum fwd engine will analyze if incoming packet is a tunneling packet.
               tunnel = 1;
else
           Csum fwd engine will not analyze if incoming packet is a tunneling packet, and treat all the incoming packets as non-tunneling packets. 
           It is used for A.


For command 2, If the hw-tunnel-mode is set/clear, which will set/clear a testpmd flag that is used in the process of how to handle tunneling packet, the pseudo-codes are list below,

if (tunnel == 1) { // this is a tunneling packet
            If (hw-tunnel-mode) 
                      ol_flags |= PKT_TX_UDP_TUNNEL_PKT;

	       Csum fwd engine set PKT_TX_UDP_TUNNEL_PKT offload flag, which means to tell HW treat  the transmit packet as a tunneling packet to do checksum offload.
	       It is used for B.1
           Else
                      Csum fwd engine doesn't  set PKT_TX_UDP_TUNNEL_PKT offload flag, which means  tell HW to treat the packet as ordinary (non-tunnelled) packet.
	      It is used for B.2
}


> 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?
>


Yes.
Your comments make sense. And I think it's just a naming problem, I will combine the two hw/sw-tunnel-mode commands into a command in order to make it  as simple and  understandable as possible.

tx_checksum set tunnel-mode (hw|none)

when user set 'hw' option,   the TESTPMD_TX_OFFLOAD_TUNNEL_CKSUM flag will be set in cmdline; actually, the PKT_TX_UDP_TUNNEL_PKT offload flag will be set if  the testpmd flag is set, which tell driver/HW treat  that  transmit packet as a tunneling packet.

When user set 'none' option, which means software and hardware will treat that packet as ordinary packet(non-tunneling).

List of commands for those cases.

Test case A:
tx_checksum set tunnel-mode none
tx_checksum set  ip   hw

test case B.1:
tx_checksum set tunnel-mode hw
tx_checksum set  ip   hw
tx_checksum set  tcp   hw

test case B.2:
tx_checksum set  ip   hw

test case C:
tx_checksum set tunnel-mode hw
tx_checksum set  outer-ip   hw
tx_checksum set  ip   hw
tx_checksum set  tcp   hw



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

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

Yes. 
Currently, i40e support outer l3, outer l4, l3 and l4 checksums offload at the same time.

test case C:
tx_checksum set tunnel-mode hw
tx_checksum set  outer-ip   hw
tx_checksum set  ip   hw
tx_checksum set  tcp   hw

Of course, outer udp is not listed here for VXLAN.

> 
> 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 l 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 l4off|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?

Thanks for your proposal.
It is clear for me.

But there are two questions for me.

As I know, in current command line framework, the option in command line is exact match, so you probably have to add duplicated codes when you want to support a new packet types.

Other question:

Currently, the following testpmd flag is for per port, not for per packet type, when they are set, which will affect whole port, not just for packet type or format, if you  add  <pkt-type> option in cmdline, which means you have to other changes.

/** Offload IP checksum in csum forward engine */
#define TESTPMD_TX_OFFLOAD_IP_CKSUM          0x0001
/** Offload UDP checksum in csum forward engine */
#define TESTPMD_TX_OFFLOAD_UDP_CKSUM         0x0002
/** Offload TCP checksum in csum forward engine */
#define TESTPMD_TX_OFFLOAD_TCP_CKSUM         0x0004
/** Offload SCTP checksum in csum forward engine */
#define TESTPMD_TX_OFFLOAD_SCTP_CKSUM        0x0008
/** Offload VxLAN checksum in csum forward engine */
#define TESTPMD_TX_OFFLOAD_VXLAN_CKSUM       0x0010

Of course, it is welcome if you can send this patch set with this idea for community review.

> Regards,
> Olivier

  reply	other threads:[~2015-01-13  3:04 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
2015-01-13  3:04                         ` Liu, Jijiang [this message]
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=1ED644BD7E0A5F4091CF203DAFB8E4CC01DA8E36@SHSMSX101.ccr.corp.intel.com \
    --to=jijiang.liu@intel.com \
    --cc=dev@dpdk.org \
    --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
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).