Re: [RFC] meta ematch

[Patrick McHardy <kaber@trash.net>]

Thomas Graf wrote:

>Found some cycles today and wrote the meta ematch. It tried to
>find a good compromise between speed and power.
>
>So far I added the following matching possibilies:
> - random
> - load average (0,1,2)
> - dev (numeric and string)
> - indev (numeric and string)
> - realdev (numeric and string)
> - skb priority
> - ... protocol
> - ... security
> - ... pkttype (to easly match on multicast/broadcast)
> - ... pktlen
> - ... datalen
> - ... maclen
> - netfilter mark
> - ... cache
> - ... conntrack info
> - ... debug variable
> - tc index
> - ... verdict
> - ... classid
> - routing classid
> - .... iif
>
>Yet to come are more routing and socket attributes such as queue
>sizes, backlog sizes, neighbour attribute of the route found, ...
>
>It is also possible to compare two kernel meta values, e.g
>realdev equals dev.
>
>Numeric matches may be modified via shift and mask operators
>to for example only consider a part of nfmark.
>
>Binary matches may have a shift modifier to only consider
>a certain amount of the data, e.g. "eth1" with shift 1 would
>end up with "eth". I added this because I wanted something
>like eth% but didn't want to implement expensive string
>operations.
>  
>
Looks great. I have a few doubts about about the set of chosen values
though. Things like nf_debug and nf_cache were never meant to be
userspace-visible. What about backwards compatibility if we want to
remove it, or some other more meaningful value where just returning 0
wouldn't be the same ?

A couple of minor things:

- var_dev sets dst->value to dev->name, meta_var_destroy will try to
  free dev->name.

- meta_int_change only uses 32 bit, but dst->value is unsigned long
  (64 bit on 64-bit arches). nfmark for example is unsigned long, so
  you should also use *(unsigned long *).

- for the same reason meta_int_compare should return long not int

>If its not obvious, random and loadavg are intended for
>load balancing purposes, i.e.
>  
>
I have my doubts about the usefullness of load balancing traffic based
on CPU load, but I guess it doesn't hurt.

Regards
Patrick