netdev - RE: [PATCH net-next V2 09/12] net/mlx5_core: Make ipv4/ipv6 location more clear

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: <063D6719AE5E284EB5DD2968C1650D6D1CCC1ECF@AcuExch.aculab.com>
Date:	Mon, 11 Jan 2016 12:17:49 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Or Gerlitz' <ogerlitz@...lanox.com>,
	"David S. Miller" <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Doug Ledford <dledford@...hat.com>,
	Matan Barak <matanb@...lanox.com>,
	Maor Gottlieb <maorg@...lanox.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Eran Ben Elisha <eranbe@...lanox.com>,
	Moni Shoua <monis@...lanox.com>
Subject: RE: [PATCH net-next V2 09/12] net/mlx5_core: Make ipv4/ipv6
 location more clear

From: Or Gerlitz
> Sent: 10 January 2016 08:40
> Change the mlx5 firmware interface header to make it
> more clear which bytes should be used by IPv4 or
> IPv6 addresses.
> 
> Signed-off-by: Maor Gottlieb <maorg@...lanox.com>
> Signed-off-by: Moni Shoua <monis@...lanox.com>
> Signed-off-by: Matan Barak <matanb@...lanox.com>
> ---
>  include/linux/mlx5/mlx5_ifc.h | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
> index 7f16695..68d73f8 100644
> --- a/include/linux/mlx5/mlx5_ifc.h
> +++ b/include/linux/mlx5/mlx5_ifc.h
> @@ -298,6 +298,22 @@ struct mlx5_ifc_odp_per_transport_service_cap_bits {
>  	u8         reserved_1[0x1a];
>  };
> 
> +struct mlx5_ifc_ipv4_layout_bits {
> +	u8         reserved_0[0x60];
> +
> +	u8         ipv4[0x20];
> +};
> +
> +struct mlx5_ifc_ipv6_layout_bits {
> +	u8         ipv6[16][0x8];
> +};
> +
> +union mlx5_ifc_ipv6_layout_ipv4_layout_auto_bits {
> +	struct mlx5_ifc_ipv6_layout_bits ipv6_layout;
> +	struct mlx5_ifc_ipv4_layout_bits ipv4_layout;
> +	u8         reserved_0[0x80];
> +};

I like the way these names just roll off the tongue :-)

> +
>  struct mlx5_ifc_fte_match_set_lyr_2_4_bits {
>  	u8         smac_47_16[0x20];
> 
> @@ -328,9 +344,9 @@ struct mlx5_ifc_fte_match_set_lyr_2_4_bits {
>  	u8         udp_sport[0x10];
>  	u8         udp_dport[0x10];
> 
> -	u8         src_ip[4][0x20];
> +	union mlx5_ifc_ipv6_layout_ipv4_layout_auto_bits src_ipv4_src_ipv6;
> 
> -	u8         dst_ip[4][0x20];
> +	union mlx5_ifc_ipv6_layout_ipv4_layout_auto_bits dst_ipv4_dst_ipv6;
>  };

Have you considered just how long the line of code to access these
fields will be?
It might be better to do (I think it compiles):
	union {
		u8	src_ipv6[16][0x8];
		struct {
			u8	src_ipv4_pad[0x60];
			u8	src_ipv4[0x20];
		}
	};
Repeated for the 'dst' addresses.
Then fixup the definition of src_ipv4[] (and probably src_ipv6[]) to
be much clearer about how the addresses are supplied.

	David