linux-kernel - Re: [PATCH v3 net-next] net: vlan: Use vlan_prio instead of vlan

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZxT3oVQ27erIoTVz@shredder.mtl.com>
Date: Sun, 20 Oct 2024 15:29:21 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Yajun Deng <yajun.deng@...ux.dev>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 net-next] net: vlan: Use vlan_prio instead of vlan_qos
 in mapping

On Fri, Oct 18, 2024 at 10:12:33PM +0800, Yajun Deng wrote:
> The vlan_qos member is used to save the vlan qos, but we only save the
> priority. Also, we will get the priority in vlan netlink and proc.
> We can just save the vlan priority using vlan_prio, so we can use vlan_prio
> to get the priority directly.
> 
> For flexibility, we introduced vlan_dev_get_egress_priority() helper
> function. After this patch, we will call vlan_dev_get_egress_priority()
> instead of vlan_dev_get_egress_qos_mask() in irdma.ko and rdma_cm.ko.
> Because we don't need the shift and mask operations anymore.
> 
> There is no functional changes.

Not sure I understand the motivation.

IIUC, currently, struct vlan_priority_tci_mapping::vlan_qos is shifted
and masked in the control path (vlan_dev_set_egress_priority) so that
these calculations would not need to be performed in the data path where
the VLAN header is constructed (vlan_dev_hard_header /
vlan_dev_hard_start_xmit).

This patch seems to move these calculations to the data path so that
they would not need to be performed in the control path when dumping the
priority mapping via netlink / proc.

Why is it a good trade-off?