On 22.03, Herbert Xu wrote: > On Sun, Mar 22, 2015 at 04:47:47AM +0000, Patrick McHardy wrote: > > > > Correct, the set extensions are added on demand and contain an offset > > for every extension type. The offset is usually not, but may be > > different for different elements. > > > > Embedding the offset is not something I want to do. Again, this stuff > > is meant to be as compact as possible and it serves no purpose at all. > > What is the problem with using these callbacks? > > Maybe I'm not seeing everything but from this patch and what > you sent me last time ([PATCH 0/9 WIP] nf_tables: set extensions > and dynamic updates) it appears that NFT_SET_EXT_KEY is always > present so if you always added it first to the template it would > be at a fixed offset, no? That's true so far, however I have a trie set implementation queued up that will make this optional. For nft_hash, sure, it will always be present, wouldn't make much sense otherwise :) The offset is currently fixed, however that's not something that is guaranteed by the implementation but purely by how the code is arranged. It would be somewhat fragile to rely on this. > But whatever, I don't really care about this so go ahead and add > the key length to obj_hash. Thanks for the review! -- 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
