netdev - Re: [PATCH net-next] net/sched: cls_flower: Add orig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210830092128.he5itvsbysvbaa5u@skbuf>
Date:   Mon, 30 Aug 2021 12:21:28 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Boris Sukholitko <boris.sukholitko@...adcom.com>
Cc:     netdev@...r.kernel.org, Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Cong Wang <xiyou.wangcong@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Vadym Kochan <vadym.kochan@...ision.eu>,
        Ilya Lifshits <ilya.lifshits@...adcom.com>
Subject: Re: [PATCH net-next] net/sched: cls_flower: Add orig_ethtype

On Mon, Aug 30, 2021 at 12:18:13PM +0300, Boris Sukholitko wrote:
> Hi Vladimir,
>
> On Mon, Aug 30, 2021 at 12:00:03PM +0300, Vladimir Oltean wrote:
> [snip]
> >
> > It is very good that you've followed up this discussion with a patch:
> > https://patchwork.kernel.org/project/netdevbpf/patch/20210617161435.8853-1-vadym.kochan@plvision.eu/
> >
> > I don't seem to see, however, in that discussion, what was the reasoning
> > that led to the introduction of a new TCA_FLOWER_KEY_ORIG_ETH_TYPE as
> > opposed to using TCA_FLOWER_KEY_ETH_TYPE?
>
> While trying to implement the plan from:
>
> https://patchwork.kernel.org/project/netdevbpf/patch/20210617161435.8853-1-vadym.kochan@plvision.eu/#24263965
>
> I've came upon the conclusion that it is better to make new orig_ethtype key
> rather than reusing TCA_FLOWER_KEY_ETH_TYPE name. The changes I've
> proposed there seem of a dubious value now. IMHO, of course :)
>
> >
> > Can you explain in English what is the objective meaning of
> > TCA_FLOWER_KEY_ORIG_ETH_TYPE, other than "what I need to solve my problem"?
>
> The orig part in the name means that the match is done on the original
> protocol field of the packet, before dissector manipulation.
>
> > Maybe an entry in the man page section in your iproute2 patch?
>
> Yes, sure, good catch! I'll send V2 of the iproute2 patch shortly.
>
> >
> > How will the VLAN case be dealt with? What is the current status quo on
> > vlan_ethtype, will a tc-flower key of "vlan_ethtype $((ETH_P_PPP_SES))"
> > match a VLAN-tagged PPP session packet or not, will the flow dissector
> > still drill deep inside the packet? I guess this is the reason why you
> > introduced another variant of the ETH_TYPE netlink attribute, to be
> > symmetric with what could be done for VLAN? But I don't see VLAN changes?
>
> For VLAN, I intend to add [c]vlan_orig_ethtype keys. I intend to send those
> (to-be-written :)) patches separately.

Wait a minute, don't hurry! We haven't even discussed offloading.
So if I am writing a driver which offloads tc-flower, do I match on
ETH_TYPE or on ORIG_ETH_TYPE? To me, the EtherType is, well, the EtherType...