netdev - Re: [PATCH 1/3] [ethtool] Add support for RX packet classification in a network device

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]

Date:	Mon, 09 Feb 2009 18:03:06 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	Santwona.Behera@....COM
Cc:	netdev@...r.kernel.org, gkernel-commit@...ts.sourceforge.net,
	jeff@...zik.org, Matheos.Worku@....COM, Mehdi.Bonyadi@....COM
Subject: Re: [PATCH 1/3] [ethtool] Add support for RX packet classification
 in a network device

From: Santwona.Behera@....COM
Date: Mon, 09 Feb 2009 15:12:21 -0800

> +struct ethtool_tcpip4_spec {
> +	__u32	ip4src;
> +	__u32	ip4dst;
> +	__u16	psrc;
> +	__u16	pdst;
> +	__u8    tos;
> +};

The IP addresses and ports in these new interfaces, are
they to be specified in network or cpu byte order?

That's usually the first thing a person will wonder when
trying to use to implement support for these interfaces.

My guess is that the specification is cpu endianness,
however note that this flies in the face with how this
is handled in pretty much every other networking interface
in the kernel.  The standard is to use network endianness
when passing ports and IP addressing information into the
kernel.

I wouldn't reject this patch series just for this reason,
in fact I'm ready to apply this stuff, but just thought I'd
mention it just in case you hadn't considered the issue
yourself.
--
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