On 07.05.2020 11:23, Xiaoliang Yang wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
Hi Allan,
Hi Vladimir,
On 06.05.2020 13:53, Vladimir Oltean wrote:
[snip]
>At the moment, the driver does not support more than 1 action. We might
>need to change that, but we can still install more filters with the
>same key and still be fine (see more below). When there is more than 1
>action, the IS1 stuff will be combined into a single rule programmed
>into IS1, and the IS2 stuff will be combined into a single new rule
>with the same keys installed into VCAP IS2. Would that not work?
>
>> The SW model have these two rules in the same table, and can stop
>> process at the first match. SW will do the action of the first frame
>> matching.
>>
>
>Actually I think this is an incorrect assumption - software stops at
>the first action only if told to do so. Let me copy-paste a text from a
>different email thread.
I'm still not able to see how this proposal will give us the same behavioral in
SW and in HW.
A simple example:
tc qdisc add dev enp0s3 ingress
tc filter add dev enp0s3 protocol 802.1Q parent ffff: \
prio 10 flower vlan_id 5 action vlan modify id 10 tc filter add dev enp0s3
protocol 802.1Q parent ffff: \
prio 20 flower src_mac 00:00:00:00:00:08 action drop
We can then inject a frame with VID 5 and smac ::08:
$ ef tx tap0 eth smac 00:00:00:00:00:08 ctag vid 5
We can then check the filter and see that it only hit the first rule:
$ tc -s filter show dev enp0s3 ingress
filter protocol 802.1Q pref 10 flower chain 0 filter protocol 802.1Q pref 10
flower chain 0 handle 0x1
vlan_id 5
not_in_hw
action order 1: vlan modify id 10 protocol 802.1Q priority 0 pipe
index 1 ref 1 bind 1 installed 19 sec used 6 sec
Action statistics:
Sent 42 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
filter protocol 802.1Q pref 20 flower chain 0 filter protocol 802.1Q pref 20
flower chain 0 handle 0x1
src_mac 00:00:00:00:00:08
not_in_hw
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1 installed 11 sec used 11 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
If this was done with the proposed HW offload, then both rules would have been
hit and we would have a different behavioral.
This can be fixed by adding the "continue" action to the first rule:
tc filter add dev enp0s3 protocol 802.1Q parent ffff: \
prio 10 flower vlan_id 5 action vlan modify id 10 continue tc filter add
dev enp0s3 protocol 802.1Q parent ffff: \
prio 20 flower src_mac 00:00:00:00:00:08 action drop
But that would again break if we add 2 rules manipulating the VLAN (as the HW
does not continue with in a single TCAM).
My point is: I do not think we can hide the fact that this is done in
independent TCAMs in the silicon.
I think it is possible to do this with the chain feature (even though it is not
a perfect match), but it would require more analysis.
/Allan
Do you mean it's better to set vlan modify filters in a different chain, and
write the filter entries with a same chain in the same VCAP TCAM?
For example:
tc filter add dev enp0s3 protocol 802.1Q chain 11 parent ffff: prio 10
flower skip_sw vlan_id 5 action vlan modify id 10
tc filter add dev enp0s3 protocol 802.1Q chain 22 parent ffff: prio 20
flower skip_sw src_mac 00:00:00:00:00:08 action drop
for this usage, we only need to ensure a chain corresponding to a VCAP in
ocelot ace driver. I'm not sure is my understanding right?
I still have not found a satisfying solution to this. As I understand
the chains, they require the "goto" action to be used to tie them
together.
We could use that to represent a single lookup in is1 and link that to a
lookup in is2. Not sure if we should, it will also require
(non-backwards compatible) changes in how the existing IS2 support is
working.
Again, I do not have the answer (I'm also looking for it), but I think
we need something where it is clear to the user that this end up in
different lists.
/Allan
