[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f18e6fee-8724-b246-adf9-53cc47f9520b@mojatatu.com>
Date: Mon, 21 Jun 2021 10:04:41 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Boris Sukholitko <boris.sukholitko@...adcom.com>,
Vladimir Oltean <olteanv@...il.com>
Cc: Vadym Kochan <vadym.kochan@...ision.eu>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Cong Wang <xiyou.wangcong@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Serhiy Boiko <serhiy.boiko@...ision.eu>,
Volodymyr Mytnyk <volodymyr.mytnyk@...ision.eu>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
jiri@...nulli.us, idosch@...sch.org, ilya.lifshits@...adcom.com
Subject: Re: [PATCH net-next] net/sched: cls_flower: fix resetting of ether
proto mask
On 2021-06-21 4:32 a.m., Boris Sukholitko wrote:
> On Thu, Jun 17, 2021 at 10:51:02PM +0300, Vladimir Oltean wrote:
>> On Thu, Jun 17, 2021 at 07:41:55PM +0300, Vladimir Oltean wrote:
>>> On Thu, Jun 17, 2021 at 07:14:35PM +0300, Vadym Kochan wrote:
>
> [snip excellent problem analysis]
>
>> So maybe it is the flow dissector we need to fix, to make it give us an
>> additional pure EtherType if asked for, make tc-flower use that
>> dissector key instead, and then revert Jamal's user space patch, and we
>> should all install our tc filters as:
>>
>> tc filter add dev sw1p0 ingress handle 11 protocol all flower eth_type 0x8864 skip_hw action drop
>>
>> ?
>
> I like this solution. To be more explicit, the plan becomes:
>
> 1. Add FLOW_DISSECTOR_KEY_ETH_TYPE and struct flow_dissector_key_eth_type.
> 2. Have skb flow dissector use it.
> 3. Userspace does not set TCA_FLOWER_KEY_ETH_TYPE automagically
> anymore. cls_flower takes basic.n_proto from struct tcf_proto.
> 4. Add eth_type to the userspace and use it to set TCA_FLOWER_KEY_ETH_TYPE
> 5. Existence of TCA_FLOWER_KEY_ETH_TYPE triggers new eth_type dissector.
>
> IMHO this neatly solves non-vlan protocol match case.
>
> What should we do with the VLANs then? Should we have vlan_pure_ethtype
> and cvlan_pure_ethtype as additional keys?
>
I didnt see the original patch you sent until after it was applied
and the cursory 30 second glance didnt say much to me.
Vlans unfortunately are a speacial beast: You will have to retrieve
the proto differently.
Q: Was this always broken? Example look at Toke's change here:
commit d7bf2ebebc2bd61ab95e2a8e33541ef282f303d4
cheers,
jamal
Powered by blists - more mailing lists