From mboxrd@z Thu Jan 1 00:00:00 1970 From: Atzm Watanabe Subject: Re: [PATCH v2] packet: Deliver VLAN TPID to userspace Date: Thu, 12 Dec 2013 19:30:44 +0900 Message-ID: <87sity744r.wl%atzm@stratosphere.co.jp> References: <8738m0q3nq.wl%atzm@stratosphere.co.jp> <87txef7dmy.wl%atzm@stratosphere.co.jp> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: , "Stephen Hemminger" , "Ben Hutchings" , "David Miller" , "Daniel Borkmann" To: "David Laight" Return-path: Received: from mail-yh0-f49.google.com ([209.85.213.49]:61264 "EHLO mail-yh0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751155Ab3LLKao (ORCPT ); Thu, 12 Dec 2013 05:30:44 -0500 Received: by mail-yh0-f49.google.com with SMTP id z20so112220yhz.36 for ; Thu, 12 Dec 2013 02:30:42 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: At Wed, 11 Dec 2013 13:19:21 -0000, David Laight wrote: > > > From: Atzm Watanabe > ... > > > You've defined a new header variant, but all the code seems to rely > > > on the fact that the 'new' variant is identical to the old one > > > with the addition of an extra field at the end. > > > > > > In which case it ought to be valid to just extend the old header variant. > > > If the header really can change format there ought to be a discriminating > > > member somewhere - which you don't seem to have changed. > > > > Yes. I think that struct tpacket3_hdr can grow safely until 48 bytes, > > so I'd just like to extend tpacket_hdr_variant1 like you said. > > > > But in the past discussions, there were mentions that a new member > > cannot be added into struct tpacket_hdr_variant1, and possibly the > > variant which includes a new member should be separated from the old > > one. > > > > http://patchwork.ozlabs.org/patch/284671/ > > http://patchwork.ozlabs.org/patch/285382/ > > I don't remember it being mentioned earlier that there are pad bytes > following the header. > > Might be worth explicitly defining the pad bytes and zeroing them. > That could make additional changes easier. Agreed. But I think that struct tpacket{2,3}_hdr can be padded but struct tpacket_hdr is not, because its size may differ depending on architectures. So I'll try to pad only to struct tpacket{2,3}_hdr. Thank you.