Hi Florian,
On Thu, Nov 14, 2024 at 12:34:41PM +0100, Florian Westphal wrote:
> Hello,
>
> nftables hides set details from userspace, in particular,
> the backend that is used to store set elements.
Right.
> For debugging it would be good to export the chosen
> backend to userspace.
>
> Another item i'd like to export is set->nelems counter.
>
> Before I start working on this, how should that look like?
>
> Option 1 is to just include two exta attributes in nf_tables_fill_set().
>
> We could restrict it to nft --debug=netlink so the information isn't
> shown by nftables but by libnftnl.
Yes, --debug=netlink or similar approach should be fine to expose the
backend implementation.
> Option 2 is to add a new type of GET request that only dumps
> such extra set info. Frontend could then support something like
>
> nft get setinfo inet mytable set3
>
> which would dump the set backend name and the set->nelems counter.
>
> Yet another option would be to include the info in normal
> list ruleset/list sets etc, but print it just like a comment, e.g.
>
> nft list ruleset
> table inet t {
> set s1 {
> type ipv4_addr # nft_rbtree_lookup
> flags interval
> elements = { 10.0.0.0-11.0.0.0, 172.16.0.0/16 }
> # nelems 4
> }
>
>
> Whats your take on this?
Exposing nelems 4 for rbtree is confusing, better expose this
implementation detail only in debug.
I would like rbtree uses the new netlink attribute representation
which provides both sides of the range rather than providing
independent elements with the flag notation, that was a early design
mistake in that API that was fixed by pipapo.
Thanks.
