From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id 6B29D5A15 for ; Wed, 21 Jan 2015 10:10:59 +0100 (CET) Received: by mail-wi0-f175.google.com with SMTP id fb4so25920050wid.2 for ; Wed, 21 Jan 2015 01:10:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3rpNWc8N5ykb+anfeAHbpTsO3zOWOq/THHrmsvgdwhE=; b=fPuOiMBdErcXgmf5jiTT5H7V6xblDV0CGEHgYhwr/IfmO8jNzRJz1aPHUXyZ6nNGk+ 78cWdCa0lncolgW0kukqTTyJ8JbcCUkHrshEyaXnZhqC4o8RfoPR/2q4B+awJVHRZ4al yz520gVjgxljZ1R3yawcGu928h24quEntPO1W7ZsxNzhjM5g8pN4oyGe5FNvGdDbNQ52 B/IwYTWYAv6Vy8XJlVQ80la0PAgt+lrNvaK385zTt7N1ac1BjX9Xia+3IqZMY0bdQkQ8 eOYs2+Qb1hlWNJyzCPvMEdMZBLg2Uh92KvD9qy8TvO3JhPabSIEbceToVEItVv3D12X9 R+ag== X-Gm-Message-State: ALoCoQkniLZfnXzRi1ZRTEx1YPyJmZbUhBasdgG4MPwhNiTL0St6eQoL0MeDtR/jfOmN+Y7CnF/y X-Received: by 10.180.8.71 with SMTP id p7mr54299516wia.17.1421831459184; Wed, 21 Jan 2015 01:10:59 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id vh8sm24634343wjc.12.2015.01.21.01.10.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 01:10:58 -0800 (PST) Message-ID: <54BF6D21.3010506@6wind.com> Date: Wed, 21 Jan 2015 10:10:57 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: "Liu, Jijiang" References: <1418173403-30202-1-git-send-email-jijiang.liu@intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA7CC5@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D3897@irsmsx105.ger.corp.intel.com> <54AFB13E.2080200@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com> <54B3B35A.5030803@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA8E36@SHSMSX101.ccr.corp.intel.com> <54B4EB92.40209@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB0789@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D4FCF@irsmsx105.ger.corp.intel.com> <54B94A18.5030700@6wind.com> <2601191342CEEE43887BDE71AB977258213DCD25@irsmsx105.ger.corp.intel.com> <54BD16F1.6050409@6wind.com> <2601191342CEEE43887BDE71AB977258213DDF46@irsmsx105.ger.corp.intel.com> <54BE4C70.7050406@6wind.com> <2601191342CEEE43887BDE71AB977258213DE5FB@irsmsx105.ger.corp.intel.com> <54BE9B56.7050108@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB56B3@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB56B3@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 09:10:59 -0000 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. Regards, Olivier