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.

Thanks,
Boris.