All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Niklas Cassel" <cassel@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Shradha Todi" <shradha.t@samsung.com>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 9/9] PCI: endpoint: Set prefetch when allocating memory for 64-bit BARs
Date: Tue, 19 Mar 2024 11:50:11 +0530	[thread overview]
Message-ID: <20240319062011.GD52500@thinkpad> (raw)
In-Reply-To: <20798a83-b2e6-4ecd-8e83-e39514b685a8@app.fastmail.com>

On Mon, Mar 18, 2024 at 07:44:21AM +0100, Arnd Bergmann wrote:
> On Mon, Mar 18, 2024, at 05:30, Manivannan Sadhasivam wrote:
> > On Fri, Mar 15, 2024 at 06:29:52PM +0100, Arnd Bergmann wrote:
> >> On Fri, Mar 15, 2024, at 07:44, Manivannan Sadhasivam wrote:
> >> > On Wed, Mar 13, 2024 at 11:58:01AM +0100, Niklas Cassel wrote:
> >
> > But I'm not sure I got the answer I was looking for. So let me rephrase my
> > question a bit.
> >
> > For BAR memory, PCIe spec states that,
> >
> > 'A PCI Express Function requesting Memory Space through a BAR must set the BAR's
> > Prefetchable bit unless the range contains locations with read side effects or
> > locations in which the Function does not tolerate write merging'
> >
> > So here, spec refers the backing memory allocated on the endpoint side as the
> > 'range' i.e, the BAR memory allocated on the host that gets mapped on the
> > endpoint.
> >
> > Currently on the endpoint side, we use dma_alloc_coherent() to allocate the
> > memory for each BAR and map it using iATU.
> >
> > So I want to know if the memory range allocated in the endpoint through
> > dma_alloc_coherent() satisfies the above two conditions in PCIe spec on all
> > architectures:
> >
> > 1. No Read side effects
> > 2. Tolerates write merging
> >
> > I believe the reason why we are allocating the coherent memory on the endpoint
> > first up is not all PCIe controllers are DMA coherent as you said above.
> 
> As far as I can tell, we never have read side effects for memory
> backed BARs, but the write merging is something that depends on
> how the memory is used:
> 
> If you have anything in that memory that relies on ordering,
> you probably want to map it as coherent on the endpoint side,
> and non-prefetchable on the host controller side, and then
> use the normal rmb()/wmb() barriers on both ends between
> serialized accesses. An example of this would be having blocks
> of data separate from metadata that says whether the data is
> valid.
> 
> If you don't care about ordering on that level, I would use
> dma_map_sg() on the endpoint side and prefetchable mapping on
> the host side, with the endpoint using dma_sync_*() to pass
> buffer ownership between the two sides, as controlled by some
> other communication method (non-prefetchable BAR, MSI, ...).
> 

Right now, there are only Test and a couple of NTB drivers making use of the
pci_epf_alloc_space() API and they do not need streaming DMA.

So to conclude, we should just live with coherent allocation/non-prefetch for
now and extend it to streaming DMA/prefetch once we have a function driver that
needs it.

Thanks a lot for your inputs!

- Mani

-- 
மணிவண்ணன் சதாசிவம்

      reply	other threads:[~2024-03-19  6:20 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-13 10:57 [PATCH v3 0/9] PCI: endpoint: set prefetchable bit for 64-bit BARs Niklas Cassel
2024-03-13 10:57 ` Niklas Cassel
2024-03-13 10:57 ` Niklas Cassel
2024-03-13 10:57 ` [PATCH v3 1/9] PCI: endpoint: pci-epf-test: Fix incorrect loop increment Niklas Cassel
2024-03-15  5:20   ` Manivannan Sadhasivam
2024-03-20 10:54     ` Niklas Cassel
2024-03-13 10:57 ` [PATCH v3 2/9] PCI: endpoint: Allocate a 64-bit BAR if that is the only option Niklas Cassel
2024-03-15  5:24   ` Manivannan Sadhasivam
2024-03-13 10:57 ` [PATCH v3 3/9] PCI: endpoint: pci-epf-test: Remove superfluous code Niklas Cassel
2024-03-15  5:25   ` Manivannan Sadhasivam
2024-03-13 10:57 ` [PATCH v3 4/9] PCI: endpoint: pci-epf-test: Simplify pci_epf_test_alloc_space() loop Niklas Cassel
2024-03-15  5:29   ` Manivannan Sadhasivam
2024-03-13 10:57 ` [PATCH v3 5/9] PCI: endpoint: pci-epf-test: Simplify pci_epf_test_set_bar() loop Niklas Cassel
2024-03-15  5:39   ` Manivannan Sadhasivam
2024-03-20 11:08     ` Niklas Cassel
2024-03-13 10:57 ` [PATCH v3 6/9] PCI: endpoint: pci-epf-test: Clean up pci_epf_test_unbind() Niklas Cassel
2024-03-15  5:42   ` Manivannan Sadhasivam
2024-03-20 11:11     ` Niklas Cassel
2024-03-13 10:57 ` [PATCH v3 7/9] PCI: cadence: Set a 64-bit BAR if requested Niklas Cassel
2024-03-15  5:46   ` Manivannan Sadhasivam
2024-03-20 11:14     ` Niklas Cassel
2024-03-13 10:58 ` [PATCH v3 8/9] PCI: rockchip-ep: " Niklas Cassel
2024-03-13 10:58   ` Niklas Cassel
2024-03-13 10:58   ` Niklas Cassel
2024-03-15  5:47   ` Manivannan Sadhasivam
2024-03-15  5:47     ` Manivannan Sadhasivam
2024-03-15  5:47     ` Manivannan Sadhasivam
2024-04-12 17:51   ` Bjorn Helgaas
2024-04-12 17:51     ` Bjorn Helgaas
2024-04-12 17:51     ` Bjorn Helgaas
2024-04-12 21:39     ` Niklas Cassel
2024-04-12 21:39       ` Niklas Cassel
2024-04-12 21:39       ` Niklas Cassel
2024-04-12 22:00       ` Bjorn Helgaas
2024-04-12 22:00         ` Bjorn Helgaas
2024-04-12 22:00         ` Bjorn Helgaas
2024-04-12 18:59   ` Bjorn Helgaas
2024-04-12 18:59     ` Bjorn Helgaas
2024-04-12 18:59     ` Bjorn Helgaas
2024-04-12 22:02     ` Niklas Cassel
2024-04-12 22:02       ` Niklas Cassel
2024-04-12 22:02       ` Niklas Cassel
2024-04-12 22:11       ` Bjorn Helgaas
2024-04-12 22:11         ` Bjorn Helgaas
2024-04-12 22:11         ` Bjorn Helgaas
2024-03-13 10:58 ` [PATCH v3 9/9] PCI: endpoint: Set prefetch when allocating memory for 64-bit BARs Niklas Cassel
2024-03-15  6:44   ` Manivannan Sadhasivam
2024-03-15 17:29     ` Arnd Bergmann
2024-03-17 11:54       ` Niklas Cassel
2024-03-18  3:53         ` Manivannan Sadhasivam
2024-03-18  7:25         ` Arnd Bergmann
2024-03-18 15:13           ` Niklas Cassel
2024-03-18 15:49             ` Arnd Bergmann
2024-03-19  6:22               ` Manivannan Sadhasivam
2024-03-18  4:30       ` Manivannan Sadhasivam
2024-03-18  6:44         ` Arnd Bergmann
2024-03-19  6:20           ` Manivannan Sadhasivam [this message]

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=20240319062011.GD52500@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=shradha.t@samsung.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.