On Mon, Nov 28, 2016 at 11:32:24AM +0100, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Mon, Nov 28, 2016 at 01:56:49AM +0100, Florian Westphal wrote: > > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > > This patch adds the chain object to the pktinfo structure. This > > > > potentially allow us to know what basechain this packet is walking over > > > > from the expression evaluation path. > > > > > > ... for what? Why...? > > > > Quota depletion event notification needs to know from what table > > delivery is happening, so this one actually belongs to the stateful > > object patchset.. > > Which patch uses this? > > I see nft_chain() call in patch 8, but it doesn't need the chain object > but uses it to fetch the table pointer. That's the only client for this new thing so far. > However, table is available at init() time so this could also be stored > in ->priv area afaics. > > [ I am not opposed to this chain store thing, but after getting rid of > a lot of members from pktinfo it seems to me we should not add > new ones without a compelling reason ] OK, nft_pktinfo is still on the 64 bytes cacheline bound. pahole reports a couple of holes there. Actually we can provide avoid those holes by reordering. better not to increase pressure there only for this. I'll follow a different path: I can store the table pointer in struct nft_object. Actually, this would be better since I can pass struct nft_object to obj->type->foo() functions instead of the ugly void * I have now, then fetch the object data area via something like nft_data_priv(obj). Thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
