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
|