On Mon, 25 Nov 2019 10:58:17 +0100 Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Mon, Nov 25, 2019 at 10:30:35AM +0100, Stefano Brivio wrote: > [...] > > Another idea could be that we get rid of this flag altogether: if we > > move "subkeys" to set->desc, the ->estimate() functions of rbtree and > > pipapo can check for those and refuse or allow set selection > > accordingly. I have no idea yet if this introduces further complexity > > for nft, because there we would need to decide how to create start/end > > elements depending on the existing set description instead of using a > > single flag. I can give it a try if it makes sense. > > nft_set_desc can probably store a boolean 'concat' that is set on if > the NFTA_SET_DESC_SUBKEY attribute is specified. Then, this flag is > not needed and you can just rely on ->estimate() as you describe. I could even just check desc->num_subkeys from your patch then, without adding another field to nft_set_desc. Too ugly? > The hashtable will just ignore this description, it does not need the > description even if userspace pass it on since the interval flag is > set on. > > You just have to update the rbtree to check for desc->concat, if this > is true, then rbtree->estimate() returns false. Yes, I think it all makes sense, thanks for detailing the idea. I'll get to this in a few hours. > BTW, then probably you can rename this attribute to > NFT_SET_DESC_CONCAT? It would include sizes, though. What about NFT_SET_DESC_SUBSIZE or NFT_SET_DESC_FIELD_SIZE? -- Stefano
