On Sat, Nov 30, 2019 at 02:53:21PM +0100, Phil Sutter wrote:
> From: Brett Mastbergen <bmastbergen@xxxxxxxxxxxx>
>
> This change allows map expressions on the left side of comparisons:
>
> nft add rule foo bar ip saddr map @map_a == 22 counter
>
> It also allows map expressions as the left side expression of other
> map expressions:
>
> nft add rule foo bar ip saddr map @map_a map @map_b == 22 counter
>
> To accomplish this, some additional context needs to be set during
> evaluation and delinearization. A tweak is also make to the parser
> logic to allow map expressions as the left hand expression to other
> map expressions.
>
> By allowing maps as left side comparison expressions one can map
> information in the packet to some arbitrary piece of data and use
> the equality (or inequality) to make some decision about the traffic,
> unlike today where the result of a map lookup is only usable as the
> right side of a statement (like dnat or snat) that actually uses the
> value as input.
>
> Signed-off-by: Brett Mastbergen <bmastbergen@xxxxxxxxxxxx>
> Signed-off-by: Phil Sutter <phil@xxxxxx>
> ---
> v2: Add testcases
> v3: Support maps on vmap LHS
>
> Pablo, Brett,
>
> Reading the discussion about pending v2 of this patch I gave it a try
> and extending functionality to verdict maps was easy and
> straightforward, so I just went ahead and extended the code accordingly.
Nice, thanks a lot for following up on this.
There is still one more case we have to cover and we go:
$ sudo nft add rule x z ip saddr map { 1.1.1.1 : 22 } vmap { 22 : accept }
Error: No symbol type information
add rule x z ip saddr map { 1.1.1.1 : 22 } vmap { 22 : accept }
^^
The existing syntax does not give us a chance to specify the right
hand side datatype. For named sets, this is fine because the set
reference implicit gives us the datatype. This information is not
available on implicit sets.
I think we have to update the syntax to include this information. For
the named set case, this will allow us to validate that actually the
specified selector and the set datatype are matching. For the implicit
sets, this will give us the datatype for the right hand side.
Otherwise, I'm afraid we will have to deal with variable length
integer, which will make things more complicated. At this stage, I
would start with strict typing, later on we can probably relax this in
the future as we find a way to reasonable infer information. This
means that a more verbose syntax, but I think that is fine.
