All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.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, "Christoph Hellwig" <hch@lst.de>
Subject: Re: [PATCH v3 9/9] PCI: endpoint: Set prefetch when allocating memory for 64-bit BARs
Date: Mon, 18 Mar 2024 16:13:37 +0100	[thread overview]
Message-ID: <ZfhaIbTcy0vgdT1A@ryzen> (raw)
In-Reply-To: <7003f4e3-fe3c-43d7-8562-efaacc3d65d3@app.fastmail.com>

Hello Arnd,

On Mon, Mar 18, 2024 at 08:25:36AM +0100, Arnd Bergmann wrote:
> 
> I'm not sure I follow this logic: If the device wants the
> buffer to act like "normal memory", then it can be marked
> as prefetchable and mapped into the host as write-combining,
> but I think in this case you *don't* want it to be coherent
> on the endpoint side either but use a streaming mapping with
> explicit cache management instead.
> 
> Conversely, if the endpoint side requires a coherent mapping,
> then I think you will want a strictly ordered (non-wc,
> non-frefetchable) mapping on the host side as well.
> 
> It would be helpful to have actual endpoint function drivers
> in the kernel rather than just the test drivers to see what type
> of serialization you actually want for best performance on
> both sides.

Yes, that would be nice.

This specific API, pci_epf_alloc_space(), is only used by the
following drivers:
drivers/pci/endpoint/functions/pci-epf-test.c
drivers/pci/endpoint/functions/pci-epf-ntb.c
drivers/pci/endpoint/functions/pci-epf-vntb.c

pci_epf_alloc_space() is only used to allocate backing
memory for the BARs.


> 
> Can you give a specific example of an endpoint that you are
> actually interested in, maybe just one that we have a host-side
> device driver for in tree?

I personally just care about pci-epf-test, but obviously I don't
want to regress any other user of pci_epf_alloc_space().

Looking at the endpoint side driver:
drivers/pci/endpoint/functions/pci-epf-test.c
and the host side driver:
drivers/misc/pci_endpoint_test.c

On the RC side, allocating buffers that the EP will DMA to is
done using: kzalloc() + dma_map_single().

On EP side:
drivers/pci/endpoint/functions/pci-epf-test.c
uses dma_map_single() when using DMA, and signals completion using MSI.

On EP side:
When reading/writing to the BARs, it simply does:
READ_ONCE()/WRITE_ONCE():
https://github.com/torvalds/linux/blob/v6.8/drivers/pci/endpoint/functions/pci-epf-test.c#L643-L648

There is no dma_sync(), so the pci-test-epf driver currently seems to
depend on the backing memory being allocated by dma_alloc_coherent().


> 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, ...).

I don't think that there is no big reason why pci-epf-test is
implemented using dma_alloc_coherent() rather than dma_sync()
for the memory backing the BARs, but that is the way it is.

Since I don't feel like totally rewriting pci-epf-test, and since
you say that we shouldn't use dma_alloc_coherent() for the memory
backing the BARs together with exporting the BAR as prefetchable,
I will drop this patch from the series in the next revision.


Kind regards,
Niklas

  reply	other threads:[~2024-03-18 15:13 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 [this message]
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

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=ZfhaIbTcy0vgdT1A@ryzen \
    --to=cassel@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=dlemoal@kernel.org \
    --cc=hch@lst.de \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.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.