From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by dpdk.org (Postfix) with ESMTP id 33F3F9AD4 for ; Tue, 3 Feb 2015 10:12:12 +0100 (CET) Received: by mail-wi0-f178.google.com with SMTP id bs8so20296085wib.5 for ; Tue, 03 Feb 2015 01:12:12 -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=UWcGE5cyaIq6DF+5LNqCMmGJtANEPo1SRYK0aKCERvE=; b=Z9bTi+olsewRd/V2vQcT//Psbwba7xArQuHy3UVz/HcSKMvymRQipE45D1FK/1P8hP 3UkCa4L/4+tJesoFrXjldm1ZoOp2aNNa+htBC14xklq7jxx3IxehQ/A0azuOZMIyN/XJ hpV0lI8q1XAbCsNxh5s+EXtv4QttBQ4hyzyoJzuPw8YC+1wAscN8DwlFe1TbijaNx1jY heqxkvL4Ib/TeUtKRGE8NFlWObvQ0cIkBfGJY4q5SIP8GvUppOz+SwNOdcBZagrqX6M3 ShOaCgLUetq64zCss54jqizuiXGfq5qvNNi3xbKPNYhrbiUoZAhOQJXINcxc7a1X2mwx spgQ== X-Gm-Message-State: ALoCoQmBBYhn9m+aQMACLxIOLCF1c7Il1KLhXe5A57Gmx/mxNrqIRR4aGdWb+I6MByNMoM3tm9oj X-Received: by 10.194.81.104 with SMTP id z8mr51797020wjx.45.1422954732078; Tue, 03 Feb 2015 01:12:12 -0800 (PST) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id i13sm31663493wjr.7.2015.02.03.01.12.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Feb 2015 01:12:11 -0800 (PST) Message-ID: <54D090EA.4040002@6wind.com> Date: Tue, 03 Feb 2015 10:12:10 +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: "Zhang, Helin" , "'dev@dpdk.org'" References: <1421637666-16872-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-2-git-send-email-helin.zhang@intel.com> <54CB8D81.2050205@6wind.com> <54CF5CF8.2090605@6wind.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 01/17] mbuf: add definitions of unified packet types 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, 03 Feb 2015 09:12:12 -0000 Hi Helin, On 02/03/2015 07:37 AM, Zhang, Helin wrote: >>> When your application decapsulates tunnels, you can just do outer = >>> inner and enter into the same code. >> Expanding packet_type is not easy, as there is no free bits in the first cache >> line. >> Is there any tunnel type in inner packet? Is it a waste? >> Is L2 type really needed? I don't know. > If it is now not short of space in mbuf, the definition as yours might be good. > But tun_type is not required for inner packet, I'd prefer to define it as needed > with taking into account the Vector PMD support. It seems 32 bits might be enough, > like below, > struct pkt_type { > uint32_t l2_type:4; > uint32_t l3_type:4; > uint32_t l4_type:4; > uint32_t tun_type:4; > uint32_t inner_l2_type:4; > uint32_t inner_l3_type:4; > uint32_t inner_l4_type:4; > } Yes, I think a structure like this would be much better! Maybe a union with a u32 could also help to assign the value in one operation. Thanks, Olivier