On 2019-01-10 8:45 a.m., Simon Horman wrote:
On Sun, Jan 06, 2019 at 09:44:30AM -0500, Jamal Hadi Salim wrote:
You can use flower instead of basic but such one offs basic would
be more effective.
Bartek, if you say you have 20 vlans: worst case scenario
here is you are going to do 20 lookups (with basic) before
hitting the efficient u32 lookup alg and of course best case
is 1 lookup.
FWIW, flower's lookup is hash-based so I would expect it to do better
than O(n).
Referring more to a large number of filters(N) in particular:
Flower will perform at O(N) to find a match (not sure
you can make it perform better than O(N)) but u32
can made to perform at _much better_ than O(logN);
i havent looked closely at Bartek's arrangement but cursory inspection
indicates he is using such an arrangement for performance.
We can add vlan as a metadata extension to u32 - just
like skb->mark is. It will help to remove the need for basic
filter but may be pushing it
That sounds more like fixing a long standing regression than a new feature
to me. I'm not sure that I understand what it would be pushing.
It will be a new feature in the sense the user will have to specify
something like (adding "mark" for clarify):
tc filter add .... protocol 802.1q .. u32 \
match u32 0 0 \
mark 15 \
vlanid 1234
action vlan pop reclassify
As opposed to what used to work before which would
have matched at packet offset.
If there is agreement (lots of bikeshedding last time)
i or someone else can whip a patch for this.
cheers,
jamal
