Hi Florian,
On Wed, Sep 18, 2019 at 3:20 PM Florian Westphal <fw@xxxxxxxxx> wrote:
>
> Hi.
>
> Following example loads fine:
> table ip NAT {
> set set1 {
> type ipv4_addr
> size 64
> flags dynamic,timeout
> timeout 1m
> }
>
> chain PREROUTING {
> type nat hook prerouting priority -101; policy accept;
> }
> }
>
> But adding/using this set doesn't work:
> nft -- add rule NAT PREROUTING tcp dport 80 ip saddr @set1 counter
> Error: Could not process rule: Operation not supported
>
If this set is only for matching, 'dynamic' is not required.
> This is because the 'dynamic' flag sets NFT_SET_EVAL.
>
> According to kernel comment, that flag means:
> * @NFT_SET_EVAL: set can be updated from the evaluation path
>
> The rule add is rejected from the lookup expression (nft_lookup_init)
> which has:
>
> if (set->flags & NFT_SET_EVAL)
> return -EOPNOTSUPP;
>
> From looking at the git history, the NFT_SET_EVAL flag means that the
> set contains expressions (i.e., a meter).
>
> And I can see why doing a lookup on meters isn't meaningful.
>
> Can someone please explain the exact precise meaning of 'dynamic'?
> Was it supposed to mean 'set can be updated from packet path'?
> Or was it supposed to mean 'set contains expressions'?
>
AFAIK, I traduce the 'dynamic' flag as a 'set that is updated from the
packet path using an expression', formerly 'meter'.
> If its the latter, do we need a new NFT_SET flag to convey 'set
> needs to support updates from packet path'?
>
In all use cases I have (mainly connection limits), 'update' is not
required so far.
> Thanks.
