On Sun, Aug 9, 2020 at 4:41 PM Jamal Hadi Salim <j...@mojatatu.com> wrote: > > Interesting idea. Note: my experience is that typical setup is > to have only one of those (from offload perspective). Ariel, > are your use cases requiring say both fields? > > From policy perspective, i think above will get more complex > mostly because you have to deal with either mark or hash > being optional. It also opens doors for more complex matching > requirements. Example "match mark X AND hash Y" and > "match mark X OR hash Y". > The new classifier will have to deal with that semantic. > > With fw and hash being the complex/optional semantics are easy: > > "match mark X AND hash Y": > $TC filter add dev $DEV1 parent ffff: protocol ip prio 3 handle X > skbhash flowid 1:12 action continue > $TC filter add dev $DEV1 parent ffff: protocol ip prio 4 handle Y fw > flowid 1:12 action ok > > "match mark X OR hash Y": > $TC filter add dev $DEV1 parent ffff: protocol ip prio 3 handle X > skbhash flowid 1:12 action ok > $TC filter add dev $DEV1 parent ffff: protocol ip prio 4 handle Y fw > flowid 1:12 action ok
Not sure if I get you correctly, but with a combined implementation you can do above too, right? Something like: (AND case) $TC filter add dev $DEV1 parent ffff: protocol ip prio 3 handle 1 skb hash Y mark X flowid 1:12 action ok (OR case) $TC filter add dev $DEV1 parent ffff: protocol ip prio 3 handle 1 skb hash Y flowid 1:12 action ok $TC filter add dev $DEV1 parent ffff: protocol ip prio 4 handle 2 skb mark X flowid 1:12 action ok Side note: you don't have to use handle as the value of hash/mark, which gives people freedom to choose different handles. > > Then the question is how to implement? is it one hash table for > both or two(one for mark and one for hash), etc. > Good question. I am not sure, maybe no hash table at all? Unless there are a lot of filters, we do not have to organize them in a hash table, do we? Thanks.
