From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by dpdk.org (Postfix) with ESMTP id 35AAA32A5 for ; Tue, 2 Dec 2014 15:53:33 +0100 (CET) Received: by mail-wi0-f170.google.com with SMTP id bs8so30139381wib.3 for ; Tue, 02 Dec 2014 06:53:33 -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:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bd3NoLPi4Crb7QNAKtlkMyWzHkASHOY/Ks4KNsjWPto=; b=P39F4udt4smWG+OYZw33E7nXF1cIsmk/IJGfDfUidL/Xbl4DXYH5EuV6VcQBB73Xos adljwOWY3J2YscnCAbaXFZEG35eBjn8JnbGFCBsgEyPXLAqGDZfQPzE6AWVBDC7o2XsD PNUR+LTFofTlFuf44Vfmm1WY+aBWGGU/P0ms1whmBMh0155Ts2EsKoUF7W89s2mZnSh0 5LfqiV/e6IyNnOL5uPJ+gIAMt29t00QcWrauMTV6gbyWnTXiG4XO+57Mz1VB1BK6Sx4g qtuQUp3Dt6Sj8iw3Avspo+I6W2oQfnZHRWPsd8IVyYotrw/yur/McoVZfXsmICIYiTa3 R7QA== X-Gm-Message-State: ALoCoQlX5StCZ564cn1VlOqkRiagxak/inn6BFKDhcOPIJBlNZ+hOg3yLI/n/1ErUDoimLvPk2Au X-Received: by 10.180.90.206 with SMTP id by14mr5835316wib.67.1417532013032; Tue, 02 Dec 2014 06:53:33 -0800 (PST) Received: from [10.16.0.123] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id bm1sm32218161wjb.45.2014.12.02.06.53.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 06:53:32 -0800 (PST) Message-ID: <547DD269.2080500@6wind.com> Date: Tue, 02 Dec 2014 15:53:29 +0100 From: "didier.pallard" Organization: 6WIND User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: jijiang.liu@intel.com, dev@dpdk.org References: <1417503172-18642-1-git-send-email-jijiang.liu@intel.com> <1417503172-18642-4-git-send-email-jijiang.liu@intel.com> In-Reply-To: <1417503172-18642-4-git-send-email-jijiang.liu@intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 3/3] mbuf:replace the inner_l2_len and the inner_l3_len 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: Tue, 02 Dec 2014 14:53:33 -0000 Hello, On 12/02/2014 07:52 AM, Jijiang Liu wrote: > Replace the inner_l2_len and the inner_l3_len field with the outer_l2_len and outer_l3_len field, and rework csum forward engine and i40e PMD due to these changes. > > Signed-off-by: Jijiang Liu [...] > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -276,8 +276,8 @@ struct rte_mbuf { > uint64_t tso_segsz:16; /**< TCP TSO segment size */ > > /* fields for TX offloading of tunnels */ > - uint64_t inner_l3_len:9; /**< inner L3 (IP) Hdr Length. */ > - uint64_t inner_l2_len:7; /**< inner L2 (MAC) Hdr Length. */ > + uint64_t outer_l3_len:9; /**< Outer L3 (IP) Hdr Length. */ > + uint64_t outer_l2_len:7; /**< Outer L2 (MAC) Hdr Length. */ > > /* uint64_t unused:8; */ > }; Sorry for entering lately this discussion, but i'm not convinced by the choice of outer_lx_len rather than inner_lx_len for new fields. I agree with Olivier that new flags should only be related to the use of new fields, to maintain coherency with oldest implementations. But from a stack point of view, i think it is better to have lx_len fields that target the outer layers, and to name new fields inner_lx_len. Let's discuss the two possibilities. 1) outer_lx_len fields are introduced. In this case, the stack should have knowledge that it is processing tunneled packets to use outer_lx_len rather than lx_len, or stack should always use outer_lx_len packet and move those fields to lx_len packets if no tunneling occurs... I think it will induce extra processing that does not seem to be really needed. 2) inner_lx_len fields are introduced. In this case, the stack first uses lx_len fields. When packet should be tunneled, lx_len fields are moved to inner_lx_len fields. Then the stack can process the outer layer and still use the lx_len fields. For example: an eth/IP/TCP forged packet will look like this: Ether/IP/UDP/xxx m->flags = IP_CKSUM m->l2_len = sizeof(ether) m->l3_len = sizeof(ip) m->l4_len = sizeof(udp) m->inner_l2_len = 0 m->inner_l3_len = 0 When entering tunnel for example a VXLAN interface, lx_len will be moved to inner_lx_len Ether/IP/UDP/xxx m->flags = INNER_IP_CKSUM m->l2_len = 0 m->l3_len = 0 m->l4_len = 0 m->inner_l2_len = sizeof(ether) m->inner_l3_len = sizeof(ip) once complete encapsulation is processed by the stack, the packet will look like Ether/IP/UDP/VXLAN/Ether/IP/UDP/xxx m->flags = IP_CKSUM | INNER_IP_CKSUM m->l2_len = sizeof(ether) m->l3_len = sizeof(ip) m->l4_len = sizeof(udp) m->inner_l2_len = sizeof(ether) + sizeof (vxlan) m->inner_l3_len = sizeof(ip) didier