From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43])
 by dpdk.org (Postfix) with ESMTP id 662CAC438
 for <dev@dpdk.org>; Tue, 30 Jun 2015 09:34:02 +0200 (CEST)
Received: by wgck11 with SMTP id k11so1693027wgc.0
 for <dev@dpdk.org>; Tue, 30 Jun 2015 00:34:02 -0700 (PDT)
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=9eWayLHEiIXAuBYe7VTkf1WnxBkpggNRANhKY+ykwUY=;
 b=ZjKjWWcgTZbUwusVAEavAO2yPVEGDtG1jYwPaUi2gs8ui5g6NQMoZ9i426oLl3HooV
 iQLnQNCyiXS3Kr3tej/XOqtrRo6UB44xHxruezItFZ61WbKpMs0wx6vuhcSjPt1bTTds
 foGjf8VrBH4yj9SX69JMpZYCkZP5JKvQPaq+N0J0bbr20cXHHGX2OPbMJ2u2HnQqnhRx
 nEv94wQGd5K5Nmyr2inkcJMnHGcRjUEGpeWxgIGBJ6iWTvQG/wrTJt7ay69DM2ZWcqX4
 GmMGpQfapwK/tCe6t14XKX8H5u+jh3sidtn6A5tM65Gahdse187CGpozihU3qt/bl3/a
 3BgQ==
X-Gm-Message-State: ALoCoQk53RqSA5tOubzFxNOHDccgUR/8I5o70OZIyFRR2yXlMf85VDBZlS7udRn2Yu6HK5Yb3zWp
X-Received: by 10.194.176.68 with SMTP id cg4mr35648485wjc.106.1435649642240; 
 Tue, 30 Jun 2015 00:34:02 -0700 (PDT)
Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.151.210])
 by mx.google.com with ESMTPSA id pf4sm67532640wjb.23.2015.06.30.00.34.01
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 30 Jun 2015 00:34:01 -0700 (PDT)
Message-ID: <5592465F.4000706@6wind.com>
Date: Tue, 30 Jun 2015 09:33:51 +0200
From: Olivier MATZ <olivier.matz@6wind.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.6.0
MIME-Version: 1.0
To: Thomas Monjalon <thomas.monjalon@6wind.com>, 
 Neil Horman <nhorman@tuxdriver.com>
References: <1433214967-22247-1-git-send-email-helin.zhang@intel.com>
 <1434006240-7271-3-git-send-email-helin.zhang@intel.com>
 <F35DEAC7BCE34641BA9FAC6BCA4A12E70A887017@SHSMSX104.ccr.corp.intel.com>
 <1516139.mFtrbLFMUC@xps13>
In-Reply-To: <1516139.mFtrbLFMUC@xps13>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3 2/7] mbuf: use the reserved 16 bits for
	double vlan
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 07:34:02 -0000

Hi,

On 06/28/2015 10:36 PM, Thomas Monjalon wrote:
> Neil, Olivier,
> Your opinions are requested here.
> Thanks
>
> 2015-06-25 08:31, Zhang, Helin:
>> Hi Neil
> [...]
>>> -279,7 +285,7 @@ struct rte_mbuf {
>>>   	uint16_t data_len;        /**< Amount of data in segment buffer. */
>>>   	uint32_t pkt_len;         /**< Total pkt len: sum of all segments. */
>>>   	uint16_t vlan_tci;        /**< VLAN Tag Control Identifier (CPU order) */
>>> -	uint16_t reserved;
>>> +	uint16_t vlan_tci_outer;  /**< Outer VLAN Tag Control Identifier (CPU
>>> +order) */
>> Do you think here is a ABI break or not? Just using the reserved 16 bits, which was
>> intended for the second_vlan_tag. Thanks in advance!
>> I did not see any "Incompatible" reported by validate_abi.sh.

I don't feel there's any ABI break here. I think an application
should not use the "reserved" fields.


Regards,
Olivier