From: Logan Gunthorpe <logang@deltatee.com>
To: Christoph Hellwig <hch@infradead.org>,
Kelvin Cao <kelvin.cao@microchip.com>
Cc: vkoul@kernel.org, dmaengine@vger.kernel.org,
linux-kernel@vger.kernel.org, george.ge@microchip.com
Subject: Re: [PATCH v2 1/1] dmaengine: switchtec-dma: Introduce Switchtec DMA engine PCI driver
Date: Tue, 11 Apr 2023 09:47:13 -0600 [thread overview]
Message-ID: <500092fe-71cc-b07c-fe6d-396a580c8252@deltatee.com> (raw)
In-Reply-To: <ZDQ8geSEauTsd2ME@infradead.org>
On 2023-04-10 10:42, Christoph Hellwig wrote:
> On Mon, Apr 03, 2023 at 11:06:28AM -0700, Kelvin Cao wrote:
>> +#define HALT_RETRY 100
>> +static int halt_channel(struct switchtec_dma_chan *swdma_chan)
>> +{
>> + u32 status;
>> + struct chan_hw_regs __iomem *chan_hw = swdma_chan->mmio_chan_hw;
>> + int retry = HALT_RETRY;
>> + struct pci_dev *pdev;
>> + int ret;
>> +
>> + rcu_read_lock();
>> + pdev = rcu_dereference(swdma_chan->swdma_dev->pdev);
>> + if (!pdev) {
>> + ret = -ENODEV;
>> + goto unlock_and_exit;
>> + }
>
> This whole RCU critical section around every access to ->pdev scheme
> looks a bit bothersome to me. This means that all the low-level
> PCI ops are done in RCU critical section. Is this something you
> came up with or is it copied from other drivers?
I suspect they copied it from plx_dma driver that I wrote ;(, though
that driver uses rcu_dereference a bit more sparingly (only on stop,
issue_pending and when allocating and freeing a channel).
> Normally we'd do an unregistration from the dmaengine subsystem
> first, which might do a RCU synchronization at a high level,
> and then we're sure that none of the methods gets called again
> on the unregistered device.
>
> Can't this driver (and the dmaengine core) support an operation
> mode where you set a shutdown flag at the beginning
The dmaengine code didn't support hot unplug at all. I believe most
drivers are likely to crash if this happens. When I wrote the plx-dma
engine, I had to make a bunch of changes to dmaengine just so the
framework didn't crash when I tested this. The framework is pretty thin,
so there's not much to synchronize on to indicate other threads are not
in the middle of issuing new IO when a flag is set.
>> + tasklet_schedule(&swdma_dev->chan_status_task);
>
> What speaks against simply using threaded irqs here instead of the
> tasklets?
Almost all the dmaengine drivers use tasklets. I don't know if this is
the best approach, but my understanding was that it was due to needing
low latency in processing the completed descriptors, otherwise it can be
hard to reach the full bandwidth of the dma engine.
Logan
next prev parent reply other threads:[~2023-04-11 15:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-03 18:06 [PATCH v2 0/1] Switchtec Switch DMA Engine Driver Kelvin Cao
2023-04-03 18:06 ` [PATCH v2 1/1] dmaengine: switchtec-dma: Introduce Switchtec DMA engine PCI driver Kelvin Cao
2023-04-03 20:26 ` Christophe JAILLET
2023-04-03 21:13 ` Kelvin.Cao
2023-04-10 16:42 ` Christoph Hellwig
2023-04-11 15:47 ` Logan Gunthorpe [this message]
2023-04-13 19:00 ` Kelvin.Cao
2023-04-13 22:40 ` Kelvin.Cao
2023-04-14 5:50 ` Christoph Hellwig
2023-04-14 23:08 ` Kelvin.Cao
2023-04-13 23:22 ` Kelvin.Cao
2023-04-14 5:57 ` Christoph Hellwig
2023-04-03 18:06 ` [PATCH v2 0/1] Switchtec Switch DMA Engine Driver Kelvin Cao
2023-04-03 18:06 ` [PATCH v2 1/1] dmaengine: switchtec-dma: Introduce Switchtec DMA engine PCI driver Kelvin Cao
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=500092fe-71cc-b07c-fe6d-396a580c8252@deltatee.com \
--to=logang@deltatee.com \
--cc=dmaengine@vger.kernel.org \
--cc=george.ge@microchip.com \
--cc=hch@infradead.org \
--cc=kelvin.cao@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vkoul@kernel.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
all inboxes | Powered by JetHome®