Messages in this thread | | | Date | Mon, 6 Feb 2023 12:48:17 +0100 | From | Simon Horman <> | Subject | Re: [PATCH net 1/2] net: mscc: ocelot: fix VCAP filters not matching on MAC with "protocol 802.1Q" |
| |
On Sun, Feb 05, 2023 at 09:24:08PM +0200, Vladimir Oltean wrote: > Alternative short title: don't instruct the hardware to match on > EtherType with "protocol 802.1Q" flower filters. It doesn't work for the > reasons detailed below. > > With a command such as the following: > > tc filter add dev $swp1 ingress chain $(IS1 2) pref 3 \ > protocol 802.1Q flower skip_sw vlan_id 200 src_mac $h1_mac \ > action vlan modify id 300 \ > action goto chain $(IS2 0 0) > > the created filter is set by ocelot_flower_parse_key() to be of type > OCELOT_VCAP_KEY_ETYPE, and etype is set to {value=0x8100, mask=0xffff}. > This gets propagated all the way to is1_entry_set() which commits it to > hardware (the VCAP_IS1_HK_ETYPE field of the key). Compare this to the > case where src_mac isn't specified - the key type is OCELOT_VCAP_KEY_ANY, > and is1_entry_set() doesn't populate VCAP_IS1_HK_ETYPE. > > The problem is that for VLAN-tagged frames, the hardware interprets the > ETYPE field as holding the encapsulated VLAN protocol. So the above > filter will only match those packets which have an encapsulated protocol > of 0x8100, rather than all packets with VLAN ID 200 and the given src_mac. > > The reason why this is allowed to occur is because, although we have a > block of code in ocelot_flower_parse_key() which sets "match_protocol" > to false when VLAN keys are present, that code executes too late. > There is another block of code, which executes for Ethernet addresses, > and has a "goto finished_key_parsing" and skips the VLAN header parsing. > By skipping it, "match_protocol" remains with the value it was > initialized with, i.e. "true", and "proto" is set to f->common.protocol, > or 0x8100. > > The concept of ignoring some keys rather than erroring out when they are > present but can't be offloaded is dubious in itself, but is present > since the initial commit fe3490e6107e ("net: mscc: ocelot: Hardware > ofload for tc flower filter"), and it's outside of the scope of this > patch to change that. > > The problem was introduced when the driver started to interpret the > flower filter's protocol, and populate the VCAP filter's ETYPE field > based on it. > > To fix this, it is sufficient to move the code that parses the VLAN keys > earlier than the "goto finished_key_parsing" instruction. This will > ensure that if we have a flower filter with both VLAN and Ethernet > address keys, it won't match on ETYPE 0x8100, because the VLAN key > parsing sets "match_protocol = false". > > Fixes: 86b956de119c ("net: mscc: ocelot: support matching on EtherType") > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
| |