On Tue, Oct 23, 2018 at 12:33:28PM +0200, Phil Sutter wrote:
> On Tue, Oct 23, 2018 at 11:28:28AM +0200, Pablo Neira Ayuso wrote:
[...]
> > Using current nftables git HEAD plus kernel patch, I'm getting:
> >
> > # nft get element ip t s '{ 25, 28 }'
> > table ip t {
> > set s {
> > type inet_service
> > flags interval
> > elements = { 20-30, 20-30 }
> > }
> > }
>
> Oh, sorry. I did above test using sources which eliminate duplicates
> from the return set (something I was playing with).
No problem :-)
> > > Here, although I ask for two elements, a single range is returned. So I
> > > guess asking for two ranges belonging to the same range should return a
> > > single range as well. Maybe a "simple" fix would be to drop duplicates
> > > from the return set?
> > >
> > > Anyway, from my point of view your solution is fine as well: If a
> > > humanoid parser evaluates the results, it can easily spot duplicates and
> > > interpret them right. If 'get element' command is used by a script to
> > > check for existence of given ranges, it all boils down to a boolean
> > > found or not found result, so duplicates shouldn't matter that much.
> >
> > My idea was to provide list including exactly the same number of
> > elements that have been requested, and in strict order, so you can
> > quickly check what you request belongs to somewhere, eg.
> >
> > # nft get element ip t s '{ 50, 20, 10 }'
> > table ip t {
> > set s {
> > type inet_service
> > flags interval
> > elements = { 50-60, 20-30, 10 }
> > }
> > }
> >
>
> Yes, that makes sense. Thanks for explaining your approach to how 'get
> element' command should work!
I should find time to document this in the manpage :-\
> > Not yet implemented, but we could add something like:
> >
> > # nft get element ip t s '{ 50, 20, 10 }'
> > table ip t {
> > set s {
> > type inet_service
> > flags interval
> > elements = { 50 in 50-60, 20 in 20-30, 10 }
> > }
> > }
> >
> > So there's a clear mapping between what we request and what we get.
>
> This would allow to return partial data, i.e. if one requested element
> doesn't exist in the set to still show the remaining ones. But current
> behaviour is absolutely fine from my point of view.
The kernel side is not allowing this, it hits ENOENT in case we find
an element which does not exist. It should be possible to revisit this
and batch several inquiries in one go.
> > Still, at this stage, the existing behaviour allows humans - for a
> > small number of data - and robots, to do mappings between what they
> > request and what they find.
>
> Yes, indeed.
Will leave this for future work, just for the record.
Thanks.
