netdev - RE: [PATCH v2 net-next] net:add one common config ARCH_WANT_RELAX

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:   Wed, 18 Jan 2017 16:22:01 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'David Miller' <davem@...emloft.net>,
        "maowenan@...wei.com" <maowenan@...wei.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
        "alexander.duyck@...il.com" <alexander.duyck@...il.com>
Subject: RE: [PATCH v2 net-next] net:add one common config
 ARCH_WANT_RELAX_ORDER to support relax ordering.

From: David Miller
> Sent: 17 January 2017 19:16
> > Relax ordering(RO) is one feature of 82599 NIC, to enable this feature can
> > enhance the performance for some cpu architecure, such as SPARC and so on.
> > Currently it only supports one special cpu architecture(SPARC) in 82599
> > driver to enable RO feature, this is not very common for other cpu architecture
> > which really needs RO feature.
> > This patch add one common config CONFIG_ARCH_WANT_RELAX_ORDER to set RO feature,
> > and should define CONFIG_ARCH_WANT_RELAX_ORDER in sparc Kconfig firstly.
> >
> > Signed-off-by: Mao Wenan <maowenan@...wei.com>
> 
> Since no-one has reviewed this patch, and I do not feel comfortable with applying
> it without such review, I am tossing this patch.
> 
> If someone eventually reviews it, repost this patch.

Having re-read parts of the PCIe spec I think I'd like someone to
explain exactly which transfers are affected by the 'relaxed ordering'
bit and why any re-ordered transactions aren't a problem.

In particular I believe RO allows the write to update the receive
descriptor ring to overtake a write of receive packet data.
That could lead to the network stack processing a receive frame
before it has actually been written.

	David