On Thu, Nov 21, 2019 at 08:55:10PM +0100, Stefano Brivio wrote: > On Wed, 20 Nov 2019 17:08:00 +0100 > Phil Sutter <phil@xxxxxx> wrote: > > > On Wed, Nov 20, 2019 at 04:16:53PM +0100, Florian Westphal wrote: > > > Stefano Brivio <sbrivio@xxxxxxxxxx> wrote: [...] > > > If not, I think we might want to expose some additional debug info > > > on set dumps. > > > > I once submitted a patch introducing NFTA_SET_OPS, an attribute holding > > set type's name in dumps. Maybe we can reuse that? It is message ID > > 20180403211540.23700-3-phil@xxxxxx (Subject: [PATCH v2 2/2] net: > > nftables: Export set backend name via netlink). > > ...I would rather try to introduce this at a later time. I just > wonder: what was the problem with that series? :) For datastructure like bitmap and hashtable, the tuning parameters are well-known probably and rather trivial for everyone. However, for composite datastructures, this is not. In general, I think the developer should better know how to optimize the tuning of the datastructure based on the description. Rather than assuming that the user knows how to tune things and exposing n-thousand knobs for configuring things. Moreover, if it turns out that we ever get something better than pipapo in the future to represent this, then we cannot transparently get rid of this code in favour of the new one. And I'm not telling I know a better way to do what you're proposing right now :-) Probably, at some point we can start exposing knobs, but I'd rather see a bit more discussions on how to provide a good autotuning. By exposing all knobs, then such discussion might not ever happen?
