netdev - Re: [PATCH net-next v7] vxlan: add support for flowlabel inherit

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: <8adb039f-00db-40a1-bcb6-4379e823fd0b@bernat.ch>
Date: Thu, 26 Oct 2023 17:53:22 +0200
From: Vincent Bernat <vincent@...nat.ch>
To: Jakub Kicinski <kuba@...nel.org>, Alce Lafranque <alce@...ranque.net>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 David Ahern <dsahern@...nel.org>, Ido Schimmel <idosch@...dia.com>,
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next v7] vxlan: add support for flowlabel inherit

On 2023-10-26 03:20, Jakub Kicinski wrote:
>>   struct vxlan_config {
>> -	union vxlan_addr	remote_ip;
>> -	union vxlan_addr	saddr;
>> -	__be32			vni;
>> -	int			remote_ifindex;
>> -	int			mtu;
>> -	__be16			dst_port;
>> -	u16			port_min;
>> -	u16			port_max;
>> -	u8			tos;
>> -	u8			ttl;
>> -	__be32			label;
>> -	u32			flags;
>> -	unsigned long		age_interval;
>> -	unsigned int		addrmax;
>> -	bool			no_share;
>> -	enum ifla_vxlan_df	df;
>> +	union vxlan_addr		remote_ip;
>> +	union vxlan_addr		saddr;
>> +	__be32				vni;
>> +	int				remote_ifindex;
>> +	int				mtu;
>> +	__be16				dst_port;
>> +	u16				port_min;
>> +	u16				port_max;
>> +	u8				tos;
>> +	u8				ttl;
>> +	__be32				label;
>> +	enum ifla_vxlan_label_policy	label_policy;
> 
> Here, OTOH, you could save some space, by making it a u8.

Is it worth it? Keeping an enum helps the compiler catching some 
mistakes and it documents a bit the code (we could put a comment 
instead). In most cases, there is not a lot of vlan_config structs lying 
around (when there are many VXLAN devices, people use single VXLAN 
devices), so it shouldn't be a problem for memory or cache.

Alternatively, we could push this to another patch that would also 
handle df field.