netdev - RE: [Intel-wired-lan] [RFC PATCH] i40e: enable PCIe relax ordering for SPARC

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:   Thu, 8 Dec 2016 10:43:15 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Alexander Duyck' <alexander.duyck@...il.com>,
        tndave <tushar.n.dave@...cle.com>
CC:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
        Netdev <netdev@...r.kernel.org>
Subject: RE: [Intel-wired-lan] [RFC PATCH] i40e: enable PCIe relax ordering
 for SPARC

From: Alexander Duyck
> Sent: 06 December 2016 17:10
...
> I was thinking about it and I realized we can probably simplify this
> even further.  In the case of most other architectures the
> DMA_ATTR_WEAK_ORDERING has no effect anyway.  So from what I can tell
> there is probably no reason not to just always pass that attribute
> with the DMA mappings.  From what I can tell the only other
> architecture that uses this is the PowerPC Cell architecture.

And I should have read all the thread :-(

> Also I was wondering if you actually needed to enable this attribute
> for both Rx and Tx buffers or just Rx buffers?  The patch that enabled
> DMA_ATTR_WEAK_ORDERING for Sparc64 seems to call out writes, but I
> didn't see anything about reads.  I'm just wondering if changing the
> code for Tx has any effect?  If not you could probably drop those
> changes and just focus on Rx.

'Weak ordering' only applies to PCIe read transfers, so can only have
an effect on descriptor reads and transmit buffer reads.

Basically PCIe is a comms protocol and an endpoint (or the host) can
have multiple outstanding read requests (each of which might generate
multiple response messages.
The responses for each request must arrive in order, but responses for
different requests can be interleaved.
Setting 'not weak ordering' lets the host interwork with broken endpoints.
(Or, like we did, you fix the fpga's PCIe implementation.)

In this case you need the reads of both transmit and receive rings to
'overtake' reads of transmit data.

I'm not at all clear how this 'flag' can be set on dma_map().
It is a property of the PCIe subsystem.

	David