Return-Path: MIME-Version: 1.0 In-Reply-To: <20150228.160047.214686672558902639.davem@davemloft.net> References: <20150228.150830.1726900309943339124.davem@davemloft.net> <20150228.160047.214686672558902639.davem@davemloft.net> Date: Sun, 1 Mar 2015 07:09:54 +0200 Message-ID: Subject: Re: [PATCH net-next v2 4/7] net: packet: use skb->dev as storage for skb orig len instead of skb->cb[] From: Eyal Birger To: David Miller Cc: Willem de Bruijn , Eric Dumazet , Shmulik Ladkani , linux-bluetooth@vger.kernel.org, Marcel Holtmann , "netdev@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 List-ID: On Sat, Feb 28, 2015 at 11:00 PM, David Miller wrote: > From: Eyal Birger > Date: Sat, 28 Feb 2015 22:38:04 +0200 > >> My concern is that any value I pick based on the existing implementations >> would need to be adjusted come a protocol with a larger address length. > > Then we need a method that requires protocols to register their > address length in a manner that will allow us to validate that > limit at compile time. > Sorry to reiterate this, but such validation will inherently become the actual limit for hardware addresses. So, it would be equivalent to changing the in-kernel definition of MAX_ADDR_SIZE. Is this something to be considered? > This is not rocket science. > > Right now we're proposing to do utterly stupid shit like encoding > integers in device pointers in the sk_buff, when that is absolutely > not necessary at all. Ok. Another suggestion I received was to delay the preparation of the full sockaddr_ll until it is needed, and store the skb original length in the first two fields (sll_protocol and sll_family) as they can be derived later on from the skb. IMHO, It would still be somewhat of a hack though. Would that approach be considered? Regards, Eyal.