From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 6A04A7F6D for ; Fri, 28 Nov 2014 11:46:16 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XuJ6x-0004io-82; Fri, 28 Nov 2014 11:49:27 +0100 Message-ID: <54785264.1020208@6wind.com> Date: Fri, 28 Nov 2014 11:45:56 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , "Liu, Jijiang" References: <1417076319-629-1-git-send-email-jijiang.liu@intel.com> <1417076319-629-2-git-send-email-jijiang.liu@intel.com> <5476F626.2020708@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9EEA0@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213BADB8@IRSMSX105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258213BAE90@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213BAE90@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields 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: Fri, 28 Nov 2014 10:46:16 -0000 Hi Konstantin, On 11/27/2014 06:01 PM, Ananyev, Konstantin wrote: >> Yes, I think it could be done that way too. >> Though I still prefer to keep l4tun_len - it makes things a bit cleaner (at least to me). >> After all we do have space for it in mbuf's tx_offload. > > As one more thing in favour of separate l4tun_len field: > l2_len is 7 bit long, so in theory it might be not enough, as for FVL: > 12:18 L4TUNLEN L4 Tunneling Length (Teredo / GRE header / VXLAN header) defined in Words. The l2_len field is 7 bits long because it was mapped to ixgbe hardware. If it's not enough (although I'm not sure it's possible to have a header larger than 128 bytes in this case), it's probably because we should not have been doing that. Maybe these generic fields should be generic :) If it's not enough, what about changing l2_len to 8 bits? Often in the recent discussions, I see as an argument "fortville needs this so we need to add it in the mbuf". I agree that currently fortville is the only hardware supported for the new features, so it can make sense to act like this, but we have to accept to come back to this API in the future if it makes less sense with other drivers. Also, application developers can be annoyed to see that the mbuf flags and meta data are just duplicating information that is already present in the packet. About the l4tun_len, it's another field the application has to fill, but it's maybe cleaner. I just wanted to clarify why I'm discussing these points. Regards, Olivier