Messages in this thread | | | Date | Wed, 6 May 2020 23:15:51 +0200 | From | "Allan W. Nielsen" <> | Subject | Re: [PATCH v1 net-next 4/6] net: mscc: ocelot: VCAP IS1 support |
| |
Hi Vladimir,
On 06.05.2020 13:53, Vladimir Oltean wrote: >On Wed, 6 May 2020 at 12:45, Allan W. Nielsen ><allan.nielsen@microchip.com> wrote: >> >> Hi Xiaoliang, >> >> On 06.05.2020 15:48, Xiaoliang Yang wrote: >> >VCAP IS1 is a VCAP module which can filter MAC, IP, VLAN, protocol, and >> >TCP/UDP ports keys, and do Qos and VLAN retag actions. >> >This patch added VCAP IS1 support in ocelot ace driver, which can supports >> >vlan modify action of tc filter. >> >Usage: >> > tc qdisc add dev swp0 ingress >> > tc filter add dev swp0 protocol 802.1Q parent ffff: flower \ >> > skip_sw vlan_id 1 vlan_prio 1 action vlan modify id 2 priority 2 >> I skimmed skimmed through the patch serie, and the way I understood it >> is that you look at the action, and if it is a VLAN operation, then you >> put it in IS1 and if it is one of the other then put it in IS2. >> >> This is how the HW is designed - I'm aware of that. >> >> But how will this work if you have 2 rules, 1 modifying the VLAN and >> another rule dropping certain packets? >> > >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
| |