From: Jiri Pirko <jiri@resnulli.us>
To: Vlad Buslov <vladbu@nvidia.com>
Cc: Jiri Pirko <jiri@nvidia.com>,
netdev@vger.kernel.org, Jamal Hadi Salim <hadi@mojatatu.com>,
Maor Dickman <maord@nvidia.com>
Subject: Re: cls_flower vlan matching
Date: Mon, 21 Mar 2022 12:24:59 +0100 [thread overview]
Message-ID: <Yjhgi48BpTGh6dig@nanopsycho> (raw)
In-Reply-To: <8735jkv2nm.fsf@nvidia.com>
Mon, Mar 14, 2022 at 06:26:38PM CET, vladbu@nvidia.com wrote:
>Hi Jiri,
>
>I've been debugging an issue that we encounter with OvS-created rules
>for single and double-VLAN packets.
>
>Basically, for flows with single VLAN OvS creates following tc filter:
>
>filter protocol 802.1Q pref 2 flower chain 0
>filter protocol 802.1Q pref 2 flower chain 0 handle 0x1
> vlan_id 10
> vlan_prio 0
> vlan_ethtype ip
> dst_mac e4:2c:0b:08:00:02
> src_mac b8:ce:f6:05:e7:3a
> eth_type ipv4
> ip_flags nofrag
> skip_hw
> not_in_hw
> action order 1: vlan pop pipe
> index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
> Action statistics:
> Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> no_percpu
>
> action order 2: mirred (Egress Redirect to device enp8s0f0_0) stolen
> index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
> Action statistics:
> Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> cookie 16a9b603144b3e0c64a887aeb972a269
> no_percpu
>
>Such rule also matches packets that have additional second VLAN header,
>even though filter has both eth_type and vlan_ethtype set to "ipv4".
>Looking at the code this seems to be mostly an artifact of the way
>flower uses flow dissector. First, even though looking at the uAPI
>eth_type and vlan_ethtype appear like a distinct fields, in flower they
>are all mapped to the same key->basic.n_proto. Second, flow dissector
>skips following VLAN header as no keys for FLOW_DISSECTOR_KEY_CVLAN are
>set and eventually assigns the value of n_proto to last parsed header.
>With these, such filters ignore any headers present between first VLAN
>header and first "non magic" header (ipv4 in this case) that doesn't
>result FLOW_DISSECT_RET_PROTO_AGAIN.
>
>Is described behavior intentional? Any way to enforce matching for
>header following the VLAN header?
Looks very much like a bug to me.
>
>Regards,
>Vlad
prev parent reply other threads:[~2022-03-21 11:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-14 17:26 cls_flower vlan matching Vlad Buslov
2022-03-21 11:24 ` Jiri Pirko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yjhgi48BpTGh6dig@nanopsycho \
--to=jiri@resnulli.us \
--cc=hadi@mojatatu.com \
--cc=jiri@nvidia.com \
--cc=maord@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=vladbu@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.