Hi Stefano,
On Tue, Feb 25, 2020 at 03:34:35PM +0100, Stefano Brivio wrote:
[...]
> This is the problem Phil reported:
[...]
> Or also simply with:
>
> # nft add element t s '{ 20-30 . 40 }'
> # nft add element t s '{ 25-35 . 40 }'
>
> the second element is silently ignored. I'm returning -EEXIST from
> nft_pipapo_insert(), but nft_add_set_elem() clears it because NLM_F_EXCL
> is not set.
>
> Are you suggesting that this is consistent and therefore not a problem?
NLM_F_EXCL !NLM_F_EXCL
exact match EEXIST 0 [*]
partial match EEXIST EEXIST
The [*] case would allow for element timeout/expiration updates from
the control plane for exact matches. Note that element updates are not
supported yet, so this check for !NLM_F_EXCL is a stub. I don't think
we should allow for updates on partial matches
I think what it is missing is a error to report "partial match" from
pipapo. Then, the core translates this "partial match" error to EEXIST
whether NLM_F_EXCL is set or not.
Would this work for you?
> Or are you proposing that I should handle this in userspace as it's done
> for non-concatenated ranges?
I don't think we should handle this from userspace. If we do so, we'll
need to get an element cache for incremental updates, that will be slow.
Thanks for explaining.
