> -----Original Message----- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Tuesday, May 26, 2015 4:35 PM > To: Ananyev, Konstantin > Cc: Zhang, Helin; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 2/5] mbuf: use the reserved 16 bits for double > vlan > > On Tue, 26 May 2015 15:02:51 +0000 > "Ananyev, Konstantin" <konstantin.ananyev at intel.com> wrote: > > > Hi Stephen, > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger > > > Sent: Tuesday, May 26, 2015 3:55 PM > > > To: Zhang, Helin > > > Cc: dev at 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 <helin.zhang at intel.com> 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 <helin.zhang at intel.com> > > > > > > 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.
But properly behaving application, shouldn't do that right? And for misbehaving ones, why should we care about them? > Yes, it would be dumb of application to do that but from absolute ABI point > of view it is a change. So, in theory, even adding a new field to the end of rte_mbuf is an ABI breakage? Konstantin
