From: Leon Romanovsky <leon@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Doug Ledford <dledford@redhat.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Adit Ranadive <aditr@vmware.com>,
Ariel Elior <aelior@marvell.com>,
Bernard Metzler <bmt@zurich.ibm.com>,
Christian Benvenuti <benve@cisco.com>,
Dennis Dalessandro <dennis.dalessandro@intel.com>,
Devesh Sharma <devesh.sharma@broadcom.com>,
Faisal Latif <faisal.latif@intel.com>,
Gal Pressman <galpress@amazon.com>, Lijun Ou <oulijun@huawei.com>,
linux-rdma@vger.kernel.org,
Michal Kalderon <mkalderon@marvell.com>,
Mike Marciniszyn <mike.marciniszyn@intel.com>,
Naresh Kumar PBS <nareshkumar.pbs@broadcom.com>,
Nelson Escobar <neescoba@cisco.com>,
Parav Pandit <parav@nvidia.com>,
Parvi Kaustubhi <pkaustub@cisco.com>,
Potnuri Bharat Teja <bharat@chelsio.com>,
Selvin Xavier <selvin.xavier@broadcom.com>,
Shiraz Saleem <shiraz.saleem@intel.com>,
Somnath Kotur <somnath.kotur@broadcom.com>,
Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>,
VMware PV-Drivers <pv-drivers@vmware.com>,
Weihang Li <liweihang@huawei.com>,
"Wei Hu(Xavier)" <huwei87@hisilicon.com>,
Yishai Hadas <yishaih@nvidia.com>,
Zhu Yanjun <yanjunz@nvidia.com>
Subject: Re: [PATCH rdma-next] RDMA: Explicitly pass in the dma_device to ib_register_device
Date: Wed, 23 Sep 2020 10:10:35 +0300 [thread overview]
Message-ID: <20200923071035.GH1223944@unreal> (raw)
In-Reply-To: <20200923065416.GA25440@infradead.org>
On Wed, Sep 23, 2020 at 07:54:16AM +0100, Christoph Hellwig wrote:
> On Wed, Sep 23, 2020 at 09:45:52AM +0300, Leon Romanovsky wrote:
> > On Wed, Sep 23, 2020 at 06:38:40AM +0100, Christoph Hellwig wrote:
> > > > +static void setup_dma_device(struct ib_device *device,
> > > > + struct device *dma_device)
> > > > {
> > > > + if (!dma_device) {
> > > > /*
> > > > + * If the caller does not provide a DMA capable device then the
> > > > + * IB device will be used. In this case the caller should fully
> > > > + * setup the ibdev for DMA. This usually means using
> > > > + * dma_virt_ops.
> > > > */
> > > > +#ifdef CONFIG_DMA_OPS
> > > > + if (WARN_ON(!device->dev.dma_ops))
> > > > + return;
> > > > +#endif
> > >
> > > dma ops are entirely optiona and NULL for the most common case
> > > (direct mapping without an IOMMU).
> >
> > IMHO we don't support such mode (without IOMMU).
>
> This seems weird. Of course I can pass in the PCI dev here at least
> in theory. Maybe it doesn't actually happen in practice, but the check
> seems totally bogus.
No problem, I will check what can be done.
>
> > > > + } else {
> > > > + device->dev.dma_parms = dma_device->dma_parms;
> > > > /*
> > > > + * Auto setup the segment size if a DMA device was passed in.
> > > > + * The PCI core sets the maximum segment size to 64 KB. Increase
> > > > + * this parameter to 2 GB.
> > > > */
> > > > + dma_set_max_seg_size(dma_device, SZ_2G);
> > >
> > > You can't just inherity DMA properties like this this. Please
> > > fix all code that looks at the seg size to look at the DMA device.
> > >
> > > Btw, where does the magic 2G come from?
> >
> > It comes from patch d10bcf947a3e ("RDMA/umem: Combine contiguous
> > PAGE_SIZE regions in SGEs"), I can't say about all devices, but this is
> > the limit for mlx5, rxe and SIW devices.
>
> If you touch this anyway I think you absolutely should move this setting
> into the drivers, and not apply a random one in the core code.
I have no idea what will be the value for other drivers, because it was
"global 2G size" before and no one complained.
Thanks
next prev parent reply other threads:[~2020-09-23 7:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 8:27 [PATCH rdma-next] RDMA: Explicitly pass in the dma_device to ib_register_device Leon Romanovsky
2020-09-22 8:58 ` Bernard Metzler
2020-09-22 10:14 ` Leon Romanovsky
2020-09-22 14:22 ` Bernard Metzler
2020-09-22 16:22 ` Jason Gunthorpe
2020-09-23 5:39 ` Christoph Hellwig
2020-09-23 18:35 ` Jason Gunthorpe
2020-09-24 5:53 ` Christoph Hellwig
2020-09-24 6:13 ` Christoph Hellwig
2020-09-24 11:55 ` Jason Gunthorpe
2020-09-24 7:31 ` Parav Pandit
2020-09-22 10:15 ` kernel test robot
2020-09-23 5:38 ` Christoph Hellwig
2020-09-23 6:45 ` Leon Romanovsky
2020-09-23 6:54 ` Christoph Hellwig
2020-09-23 7:10 ` Leon Romanovsky [this message]
2020-09-23 7:21 ` Christoph Hellwig
2020-09-23 18:34 ` Jason Gunthorpe
2020-09-24 5:49 ` Christoph Hellwig
2020-09-24 11:49 ` Jason Gunthorpe
2020-10-06 14:29 ` Bart Van Assche
2020-10-06 16:53 ` Jason Gunthorpe
2020-10-06 18:22 ` Bart Van Assche
2020-10-06 18:39 ` Jason Gunthorpe
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=20200923071035.GH1223944@unreal \
--to=leon@kernel.org \
--cc=aditr@vmware.com \
--cc=aelior@marvell.com \
--cc=benve@cisco.com \
--cc=bharat@chelsio.com \
--cc=bmt@zurich.ibm.com \
--cc=dennis.dalessandro@intel.com \
--cc=devesh.sharma@broadcom.com \
--cc=dledford@redhat.com \
--cc=faisal.latif@intel.com \
--cc=galpress@amazon.com \
--cc=hch@infradead.org \
--cc=huwei87@hisilicon.com \
--cc=jgg@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=liweihang@huawei.com \
--cc=mike.marciniszyn@intel.com \
--cc=mkalderon@marvell.com \
--cc=nareshkumar.pbs@broadcom.com \
--cc=neescoba@cisco.com \
--cc=oulijun@huawei.com \
--cc=parav@nvidia.com \
--cc=pkaustub@cisco.com \
--cc=pv-drivers@vmware.com \
--cc=selvin.xavier@broadcom.com \
--cc=shiraz.saleem@intel.com \
--cc=somnath.kotur@broadcom.com \
--cc=sriharsha.basavapatna@broadcom.com \
--cc=yanjunz@nvidia.com \
--cc=yishaih@nvidia.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.