DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>,
	"Liu, Jijiang" <jijiang.liu@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: Wed, 21 Jan 2015 11:52:08 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258213DE8F0@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <54BF6D21.3010506@6wind.com>



> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Wednesday, January 21, 2015 9:11 AM
> To: Liu, Jijiang
> Cc: Ananyev, Konstantin; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine
> 
> Hi Jijiang,
> 
> On 01/21/2015 09:01 AM, Liu, Jijiang wrote:
> >>> I still don't understand why you are so eager to 'forbid' it.
> >>> Yes we support it for FVL, but no one forces you to use it.
> >>
> >> Well, how would you describe this 2 ways of doing the same thing in the
> >> offload API? Would you talk about the i40e registers? It's not because i40e
> >> has 2 ways to do the same operation that the DPDK should do the same.
> >>
> >> How will you explain to a user how to choose between these 2 cases?
> >
> > Talk about B method in http://dpdk.org/ml/archives/dev/2014-December/009213.html again.
> >
> > DPDK Never supports a  NIC that can recognize tunneling packet for TX side before 1.8, right?
> 
> When you say "recognize tunnel", if you mean offlading checksum of
> tunnel headers, I agree.
> 
> If you mean recognizing a tunnel packet in rx, I also agree
> it's new to dpdk-1.8, but I think it's unrelated to what we
> are talking about, which is tx checksum. A DPDK application
> is able to generate tunnel packets by itself and offload the
> checksums to the NIC.
> 
> > So when we need to support TX checksum offload for tunneling packet,  and we have to choose B.2.
> 
> I don't see why we should choose either B.1 or B.2 (I guess you want
> to say B.1 here, right?).
> 
> The m->lX_len are not filled in rx today. If one day they are, it won't
> prevent the application to configure the lX_len fields and offload
> flags according to the API.
> 
> > After introducing i40e(FVL),  FVL is able to recognize tunneling packet and  support outer IP, or inner IP or outer IP and inner IP TX
> checksum for tunneling packet.
> > And you agree on "outer and inner at the same time", why do you object "only inner"?
> >
> > Actually, B.2 method is a software workaround using L2 length when NIC can't recognize tunneling packet.
> > When NIC is able to recognize tunneling packet, I think you shouldn't take B.2 as a standard to 'forbid' other method.
> 
> Again, I'm not sure there is a link between "recognizing tunneling
> packets" and tx checksum offload of tunnels. 

I think what Jijiang doesn't talk about RX here.
What he is trying to say that with B.2 (case 4) we hide from HW the fact that the packet is tunnelling.
We just using the fact, that to calculate cksum for inner packet only, HW doesn't need to know is it a tunnelling packet or not.
All it needs is a proper values of l2_len and l3_len. 

> 
> Regards,
> Olivier

  reply	other threads:[~2015-01-21 11:52 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
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 [this message]
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=2601191342CEEE43887BDE71AB977258213DE8F0@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=dev@dpdk.org \
    --cc=jijiang.liu@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
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).