From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by dpdk.org (Postfix) with ESMTP id 187689A92 for ; Tue, 26 May 2015 17:35:03 +0200 (CEST) Received: by pdbqa5 with SMTP id qa5so93359202pdb.0 for ; Tue, 26 May 2015 08:35: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:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=PxmKpLyFdCVAqDpaTPjLqZuIoDsCk/UtEW9IKdnxV4w=; b=h7h+mwua6g8xCM9l4WQJFtEK9EW81ywa+5Zh6G3LXKrmFuejjcDDCw1UdMR+5wvq6I WpznwRwGOgMk3vNnvFPmsOo1ILJrYd+e7ClzNmP8jAFtSv6KDtUJbTY4IUyggaQ6vOE+ rqabNWIRwVzYil/YVgiQgzfEVEDG91fDVkGwxEUQkpifGaGyyvmFh9G1ILZyelepWU0K 4lOyEffpf712GpyQAHu7ZNkOQAdh4c9r8s7GusLbhq4E1qcUMY/Zl9L6fgz3WmOLi9q+ IIZeAnJdRXnTrpVr16BgnQIUWpkh6WxemF6oZ6tRiDruWR9w1LHECb7/7fxn7lHkg8EX Q1IQ== X-Gm-Message-State: ALoCoQkjKThnm+OV34hPRIFsEHQDbS1ftJXQjdXgvDdWH4DNdhj8vn7hYsyrlj2U6RDimy80KoBW X-Received: by 10.69.27.66 with SMTP id je2mr29072421pbd.156.1432654502355; Tue, 26 May 2015 08:35:02 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id yv6sm13505497pac.29.2015.05.26.08.35.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 08:35:02 -0700 (PDT) Date: Tue, 26 May 2015 08:35:05 -0700 From: Stephen Hemminger To: "Ananyev, Konstantin" Message-ID: <20150526083505.247e5431@urahara> In-Reply-To: <2601191342CEEE43887BDE71AB97725821431C8F@irsmsx105.ger.corp.intel.com> References: <1430793143-3610-1-git-send-email-helin.zhang@intel.com> <1432629400-25303-1-git-send-email-helin.zhang@intel.com> <1432629400-25303-3-git-send-email-helin.zhang@intel.com> <20150526075515.1bc42ae1@urahara> <2601191342CEEE43887BDE71AB97725821431C8F@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 2/5] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:35:03 -0000 On Tue, 26 May 2015 15:02:51 +0000 "Ananyev, Konstantin" wrote: > Hi Stephen, > > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Tuesday, May 26, 2015 3:55 PM > > To: Zhang, Helin > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 2/5] mbuf: use the reserved 16 bits for double vlan > > > > On Tue, 26 May 2015 16:36:37 +0800 > > Helin Zhang wrote: > > > > > Use the reserved 16 bits in rte_mbuf structure for the outer vlan, > > > also add QinQ offloading flags for both RX and TX sides. > > > > > > Signed-off-by: Helin Zhang > > > > Yet another change that is much needed, but breaks ABI compatibility. > > Why do you think it breaks ABI compatibility? > As I can see, it uses field that was reserved. > Konstantin Because an application maybe assuming something or reusing the reserved fields. Yes, it would be dumb of application to do that but from absolute ABI point of view it is a change.