[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150309173515.GB30297@breakpoint.cc>
Date: Mon, 9 Mar 2015 18:35:15 +0100
From: Florian Westphal <fw@...len.de>
To: David Miller <davem@...hat.com>
Cc: fw@...len.de, pablo@...filter.org, netfilter-devel@...r.kernel.org,
netdev@...r.kernel.org, azhou@...ira.com
Subject: Re: [PATCH nf-next 0/8] netfilter: untangle bridge and bridge
netfilter
David Miller <davem@...hat.com> wrote:
> > The 2nd (and last half) of the set folds nf_bridge_info into skbuff,
> > at the end (where its not initialized at allocation time).
> >
> > The struct is a lot smaller by then (16 bytes on 64bit, 12 on 32bit)
> > so we'd increase skbuff size only by 8.
>
> Sorry, increases in size of any kind of sk_buff are strongly discouraged.
No need to be sorry, its not a show-stopper.
Its the last patch in the series and nothing depends on this change.
> Especially for something like nfbridge.
Its not initialized, ever, if bridge is not used, so it shouldn't be a big
deal. The goal of the entire exercise is to remove the need to zero
nf_bridge pointer at skb allocation time, so one of the patches in that
series moves it to the end of the skb.
The only reason why I added the 'fold it' patch on top is that after the
refactoring nf_bridge_info struct is just 16 bytes so it seemed
preferrable to me to add cost of 8 more bytes and get rid of the
nf_bridge refcounting at same time.
I'd just send it along with the series so everyone can look at it,
and, if you (or others) still prefer to keep the pointer then Pablo can
just drop it.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists