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] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CB8970A@AcuExch.aculab.com>
Date:	Fri, 28 Aug 2015 14:03:56 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'David Ahern' <dsa@...ulusnetworks.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 3/5] net: Add helper function to compare
 inetpeer addresses

From: David Ahern
> Sent: 27 August 2015 22:17
ATCH net-next 3/5] net: Add helper function to compare inetpeer addresses
> 
> tcp_metrics and inetpeer both have functions to compare inetpeer
> addresses. Consolidate into 1 version.
> 
> Signed-off-by: David Ahern <dsa@...ulusnetworks.com>
> ---
...
> diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
> index f75b9e7036a2..9d9b3446731d 100644
> --- a/include/net/inetpeer.h
> +++ b/include/net/inetpeer.h
> @@ -121,6 +121,22 @@ static inline struct inet_peer *inet_getpeer_v6(struct inet_peer_base *base,
>  	return inet_getpeer(base, &daddr, create);
>  }
> 
> +static inline int inetpeer_addr_cmp(const struct inetpeer_addr *a,
> +				    const struct inetpeer_addr *b)
> +{
> +	int i, n = (a->family == AF_INET ? 1 : 4);
> +
> +	for (i = 0; i < n; i++) {
> +		if (a->addr.a6[i] == b->addr.a6[i])
> +			continue;
> +		if ((__force u32)a->addr.a6[i] < (__force u32)b->addr.a6[i])
> +			return -1;
> +		return 1;
> +	}
> +
> +	return 0;
> +}

If the performance of this matters then I'd not use the loop for IPv4
and use u64 comparisons (esp. on 64 bit systems) in an unrolled loop for IPv6.
(Might need to worry about the alignment.)

I presume nothing cares that the ordering relation is endian dependant?
With either byteswapping memory reads or a byteswapping instruction
then an endian-independant ordering should be almost as quick.

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ