linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Johannes Berg' <johannes@sipsolutions.net>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Maxime Bizon" <mbizon@freebox.fr>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Oleksandr Natalenko" <oleksandr@natalenko.name>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Kalle Valo" <kvalo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Olha Cherevyk" <olha.cherevyk@gmail.com>,
	iommu <iommu@lists.linux-foundation.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Netdev <netdev@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	stable <stable@vger.kernel.org>
Subject: RE: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP
Date: Fri, 25 Mar 2022 21:40:20 +0000	[thread overview]
Message-ID: <19b4ad5f9909446ea0eca93f9b5b4c40@AcuMS.aculab.com> (raw)
In-Reply-To: <e42e4c8bf35b62c671ec20ec6c21a43216e7daa6.camel@sipsolutions.net>

I've been thinking of the case where a descriptor ring has
to be in non-coherent memory (eg because that is all there is).

The receive ring processing isn't actually that difficult.

The driver has to fill a cache line full of new buffer
descriptors in memory but without assigning the first
buffer to the hardware.
Then it has to do a cache line write of just that line.
Then it can assign ownership of the first buffer and
finally do a second cache line write.
(The first explicit write can be skipped if the cache
writes are known to be atomic.)
It then must not dirty that cache line.

To check for new frames it must invalidate the cache
line that contains the 'next to be filled' descriptor
and then read that cache line.
This will contain info about one or more receive frames.
But the hardware is still doing updates.

But both these operations can be happening at the same
time on different parts of the buffer.

So you need to know a 'cache line size' for the mapping
and be able to do writebacks and invalidates for parts
of the buffer, not just all of it.

The transmit side is harder.
It either requires waiting for all pending transmits to
finish or splitting a single transmit into enough fragments
that its descriptors end on a cache line boundary.
But again, and if the interface is busy, you want the cpu
to be able to update one cache line of transmit descriptors
while the device is writing transmit completion status
to the previous cache line.

I don't think that is materially different for non-coherent
memory or bounce buffers.
But partial flush/invalidate is needed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2022-03-25 21:40 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23  7:19 [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP Oleksandr Natalenko
2022-03-23  7:28 ` Kalle Valo
2022-03-23 17:27 ` Linus Torvalds
2022-03-23 19:06   ` Robin Murphy
2022-03-23 19:16     ` Linus Torvalds
2022-03-23 20:54       ` Robin Murphy
2022-03-24  5:57         ` Christoph Hellwig
2022-03-24 10:25           ` Oleksandr Natalenko
2022-03-24 11:05             ` Robin Murphy
2022-03-24 14:27               ` Toke Høiland-Jørgensen
2022-03-24 16:29                 ` Maxime Bizon
2022-03-24 16:31                   ` Christoph Hellwig
2022-03-24 16:52                     ` Robin Murphy
2022-03-24 17:07                       ` Toke Høiland-Jørgensen
2022-03-24 19:26                         ` Linus Torvalds
2022-03-24 21:14                           ` Toke Høiland-Jørgensen
2022-03-25 10:25                           ` Maxime Bizon
2022-03-25 11:27                             ` Robin Murphy
2022-03-25 23:38                               ` Halil Pasic
2022-03-26 16:05                                 ` Toke Høiland-Jørgensen
2022-03-26 18:38                                   ` Linus Torvalds
2022-03-26 22:38                                     ` David Laight
2022-03-26 22:41                                       ` Linus Torvalds
2022-03-25 16:25                             ` Toke Høiland-Jørgensen
2022-03-25 16:45                               ` Robin Murphy
2022-03-25 18:13                                 ` Toke Høiland-Jørgensen
2022-03-25 18:30                             ` Linus Torvalds
2022-03-25 19:14                               ` Robin Murphy
2022-03-25 19:21                                 ` Linus Torvalds
2022-03-25 19:26                               ` Oleksandr Natalenko
2022-03-25 19:27                                 ` Linus Torvalds
2022-03-25 19:35                                   ` Oleksandr Natalenko
2022-03-25 20:37                               ` Johannes Berg
2022-03-25 20:47                                 ` Linus Torvalds
2022-03-25 21:13                                   ` Johannes Berg
2022-03-25 21:40                                     ` David Laight [this message]
2022-03-25 21:56                                     ` Linus Torvalds
2022-03-25 22:41                                       ` David Laight
2022-03-27  3:15                                     ` Halil Pasic
2022-03-28  9:48                                       ` Johannes Berg
2022-03-28  9:50                                         ` Johannes Berg
2022-03-28  9:57                                           ` Johannes Berg
2022-03-27  3:48                           ` Halil Pasic
2022-03-27  5:06                             ` Linus Torvalds
2022-03-27  5:21                               ` Linus Torvalds
2022-03-27 15:24                                 ` David Laight
2022-03-27 19:23                                   ` Linus Torvalds
2022-03-27 20:04                                     ` Linus Torvalds
2022-03-27 23:52                                 ` Halil Pasic
2022-03-28  0:30                                   ` Linus Torvalds
2022-03-28 12:02                                     ` Halil Pasic
2022-03-27 23:37                               ` Halil Pasic
2022-03-28  0:37                                 ` Linus Torvalds
2022-03-25  7:12                         ` Oleksandr Natalenko
2022-03-25  9:21                           ` Thorsten Leemhuis
2022-03-24 18:31                       ` Halil Pasic
2022-03-25 16:31                         ` Christoph Hellwig
2022-03-24 18:02         ` Halil Pasic
2022-03-25 15:25           ` Halil Pasic
2022-03-25 16:23             ` Robin Murphy
2022-03-25 16:32           ` Christoph Hellwig
2022-03-25 18:15             ` Toke Høiland-Jørgensen
2022-03-25 18:42               ` Robin Murphy
2022-03-25 18:46                 ` Linus Torvalds
2022-03-28  6:37                   ` Christoph Hellwig
2022-03-28  8:15                     ` David Laight
2022-03-30 12:11                     ` Halil Pasic
2022-03-24  8:55   ` Oleksandr Natalenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19b4ad5f9909446ea0eca93f9b5b4c40@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mbizon@freebox.fr \
    --cc=netdev@vger.kernel.org \
    --cc=oleksandr@natalenko.name \
    --cc=olha.cherevyk@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=robin.murphy@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=toke@toke.dk \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).