| Message ID | 20200311135158.3310-2-christian.koenig@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/6] lib/scatterlist: add sg_set_dma_addr() function | expand |
On Wed, Mar 11, 2020 at 02:51:53PM +0100, Christian König wrote: > This can be used by drivers to setup P2P DMA between device > memory which is not backed by struct pages. > > The drivers of the involved devices are responsible for > setting up and tearing down DMA addresses as necessary > using dma_map_resource(). > > The page pointer is set to NULL and only the DMA address, > length and offset values are valid. NAK. The only valid way to fill DMA address in scatterlists is dma_map_sg / dma_map_sg_attr.
Am 11.03.20 um 16:28 schrieb Christoph Hellwig: > On Wed, Mar 11, 2020 at 02:51:53PM +0100, Christian König wrote: >> This can be used by drivers to setup P2P DMA between device >> memory which is not backed by struct pages. >> >> The drivers of the involved devices are responsible for >> setting up and tearing down DMA addresses as necessary >> using dma_map_resource(). >> >> The page pointer is set to NULL and only the DMA address, >> length and offset values are valid. > NAK. The only valid way to fill DMA address in scatterlists is > dma_map_sg / dma_map_sg_attr. How can we then map PCIe BARs into an scatterlist which are not backed by struct pages? Regards, Christian.
On Thu, Mar 12, 2020 at 11:14:22AM +0100, Christian König wrote: > > > The page pointer is set to NULL and only the DMA address, > > > length and offset values are valid. > > NAK. The only valid way to fill DMA address in scatterlists is > > dma_map_sg / dma_map_sg_attr. > > How can we then map PCIe BARs into an scatterlist which are not backed by > struct pages? You can't. scatterlists by definition map memory backed by a struct page. If you want to map something else struct scatterlist is the wrong structure and you need to use something else (which you should anyway as struct scatterlist is a bad design patter, and the above is only one of the many issues with it).
Am 12.03.20 um 11:19 schrieb Christoph Hellwig: > On Thu, Mar 12, 2020 at 11:14:22AM +0100, Christian König wrote: >>>> The page pointer is set to NULL and only the DMA address, >>>> length and offset values are valid. >>> NAK. The only valid way to fill DMA address in scatterlists is >>> dma_map_sg / dma_map_sg_attr. >> How can we then map PCIe BARs into an scatterlist which are not backed by >> struct pages? > You can't. scatterlists by definition map memory backed by a struct > page. If you want to map something else struct scatterlist is the > wrong structure and you need to use something else (which you should > anyway as struct scatterlist is a bad design patter, and the above > is only one of the many issues with it). But how should we then deal with all the existing interfaces which already take a scatterlist/sg_table ? The whole DMA-buf design and a lot of drivers are build around scatterlist/sg_table and to me that actually makes quite a lot of sense. For TTM I'm also trying for quite a while to just nuke the manual dma_address arrays we have and switch over to scatterlist/sg_table. I mean we could come up with a new structure for this, but to me that just looks like reinventing the wheel. Especially since drivers need to be able to handle both I/O to system memory and I/O to PCIe BARs. Regards, Christian.
On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote: > But how should we then deal with all the existing interfaces which already > take a scatterlist/sg_table ? > > The whole DMA-buf design and a lot of drivers are build around > scatterlist/sg_table and to me that actually makes quite a lot of sense. > Replace them with a saner interface that doesn't take a scatterlist. At very least for new functionality like peer to peer DMA, but especially this code would also benefit from a general move away from the scatterlist. > For TTM I'm also trying for quite a while to just nuke the manual > dma_address arrays we have and switch over to scatterlist/sg_table. Which is a move in the wrong direction. > I mean we could come up with a new structure for this, but to me that just > looks like reinventing the wheel. Especially since drivers need to be able > to handle both I/O to system memory and I/O to PCIe BARs. The structure for holding the struct page side of the scatterlist is called struct bio_vec, so far mostly used by the block and networking code. The structure for holding dma addresses doesn't really exist in a generic form, but would be an array of these structures: struct dma_sg { dma_addr_t addr; u32 len; }; Keeping them separate is important as most IOMMU drivers will return less entries than you can feed them. E.g. if your input boundaries are 4k aligned you will usually just get a single IOVA entry back. I will soon also have a dma mapping interface that will take advantage of that fact.
Am 12.03.20 um 11:47 schrieb Christoph Hellwig: > On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote: > [SNIP] >> I mean we could come up with a new structure for this, but to me that just >> looks like reinventing the wheel. Especially since drivers need to be able >> to handle both I/O to system memory and I/O to PCIe BARs. > The structure for holding the struct page side of the scatterlist is > called struct bio_vec, so far mostly used by the block and networking > code. Yeah, I'm aware of this. > The structure for holding dma addresses doesn't really exist > in a generic form, but would be an array of these structures: > > struct dma_sg { > dma_addr_t addr; > u32 len; > }; So the whole idea is to nuke scatterlist/sg_table in the long term and switch over to using bio_vec as input and dma_sg as output for a DMA mapping operation. Is that correct? If yes I could live with that, but it makes my patchset much more complicated. > Keeping them separate is important as most IOMMU drivers will return > less entries than you can feed them. E.g. if your input boundaries > are 4k aligned you will usually just get a single IOVA entry back. > I will soon also have a dma mapping interface that will take advantage > of that fact. Yeah, I noticed as well that this is not really well handled. Thanks for the feedback, Christian.
Am 12.03.20 um 15:19 schrieb Jason Gunthorpe: > On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote: >> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote: >>> But how should we then deal with all the existing interfaces which already >>> take a scatterlist/sg_table ? >>> >>> The whole DMA-buf design and a lot of drivers are build around >>> scatterlist/sg_table and to me that actually makes quite a lot of sense. >>> >> Replace them with a saner interface that doesn't take a scatterlist. >> At very least for new functionality like peer to peer DMA, but >> especially this code would also benefit from a general move away >> from the scatterlist. > If dma buf can do P2P I'd like to see support for consuming a dmabuf > in RDMA. That would indeed be awesome. > Looking at how.. there is an existing sgl based path starting > from get_user_pages through dma map to the drivers. (ib_umem) > > I can replace the driver part with something else (dma_sg), but not > until we get a way to DMA map pages directly into that something > else.. > > The non-page scatterlist is also a big concern for RDMA as we have > drivers that want the page list, so even if we did as this series > contemplates I'd have still have to split the drivers and create the > notion of a dma-only SGL. Yeah that's my concern as well. For GPU drivers I don't think we need the struct pages anywhere, but that might not be true for others. >>> I mean we could come up with a new structure for this, but to me that just >>> looks like reinventing the wheel. Especially since drivers need to be able >>> to handle both I/O to system memory and I/O to PCIe BARs. >> The structure for holding the struct page side of the scatterlist is >> called struct bio_vec, so far mostly used by the block and networking >> code. > I haven't used bio_vecs before, do they support chaining like SGL so > they can be very big? RDMA dma maps gigabytes of memory > >> The structure for holding dma addresses doesn't really exist >> in a generic form, but would be an array of these structures: >> >> struct dma_sg { >> dma_addr_t addr; >> u32 len; >> }; > Same question, RDMA needs to represent gigabytes of pages in a DMA > list, we will need some generic way to handle that. I suspect GPU has > a similar need? Can it be accomidated in some generic dma_sg? Yes, we easily have ranges of >1GB. So I would certainly say u64 for the len here. > So I'm guessing the path forward is something like > > - Add some generic dma_sg data structure and helper > - Add dma mapping code to go from pages to dma_sg > - Rework RDMA to use dma_sg and the new dma mapping code > - Rework dmabuf to support dma mapping to a dma_sg > - Rework GPU drivers to use dma_sg > - Teach p2pdma to generate a dma_sg from a BAR page list > - This series > > ? Sounds pretty much like a plan to me, but unfortunately like a rather huge one. Because of this and cause I don't know if all drivers can live with dma_sg I'm not sure if we shouldn't have the switch from scatterlist to dma_sg separately to this peer2peer work. Christian. > > Jason
On 2020-03-12 8:19 a.m., Jason Gunthorpe wrote: > On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote: >> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote: >>> But how should we then deal with all the existing interfaces which already >>> take a scatterlist/sg_table ? >>> >>> The whole DMA-buf design and a lot of drivers are build around >>> scatterlist/sg_table and to me that actually makes quite a lot of sense. >>> >> >> Replace them with a saner interface that doesn't take a scatterlist. >> At very least for new functionality like peer to peer DMA, but >> especially this code would also benefit from a general move away >> from the scatterlist. > > If dma buf can do P2P I'd like to see support for consuming a dmabuf > in RDMA. Looking at how.. there is an existing sgl based path starting > from get_user_pages through dma map to the drivers. (ib_umem) > > I can replace the driver part with something else (dma_sg), but not > until we get a way to DMA map pages directly into that something > else.. > > The non-page scatterlist is also a big concern for RDMA as we have > drivers that want the page list, so even if we did as this series > contemplates I'd have still have to split the drivers and create the > notion of a dma-only SGL. > >>> I mean we could come up with a new structure for this, but to me that just >>> looks like reinventing the wheel. Especially since drivers need to be able >>> to handle both I/O to system memory and I/O to PCIe BARs. >> >> The structure for holding the struct page side of the scatterlist is >> called struct bio_vec, so far mostly used by the block and networking >> code. > > I haven't used bio_vecs before, do they support chaining like SGL so > they can be very big? RDMA dma maps gigabytes of memory bio_vec's themselves don't support chaining... In the block layer they are used in a struct bio which handles chaining, splitting and other features. Each bio, though, has a limit of 256 segments to avoid higher order allocations. Depending on your use case, you could reuse bios or write your own container to chain bio_vecs. >> The structure for holding dma addresses doesn't really exist >> in a generic form, but would be an array of these structures: >> >> struct dma_sg { >> dma_addr_t addr; >> u32 len; >> }; > Yes, we easily have ranges of >1GB. So I would certainly say u64 for the len here. I'd probably avoid the u64 here and leave space for some flags or something. If you have >1GB to map you can always just have mulitple segments. With 4GB per segment and 256 segments per page, a page of DMA sgs can easily map 1TB of memory in a single call and with chaining or larger allocations you can extend that further, if needed. Logan
On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: > The non-page scatterlist is also a big concern for RDMA as we have > drivers that want the page list, so even if we did as this series > contemplates I'd have still have to split the drivers and create the > notion of a dma-only SGL. The drivers I looked at want a list of IOVA address, aligned to the device "page size". What other data do drivers want? Execept for the software protocol stack drivers, which of couse need pages for the stack futher down. > I haven't used bio_vecs before, do they support chaining like SGL so > they can be very big? RDMA dma maps gigabytes of memory bio_vecs itself don't have the chaining, but the bios build around them do. But each entry can map a huge pile. If needed we could use the same chaining scheme we use for scatterlists for bio_vecs as well, but lets see if we really end up needing that. > So I'm guessing the path forward is something like > > - Add some generic dma_sg data structure and helper > - Add dma mapping code to go from pages to dma_sg That has been on my todo list for a while. All the DMA consolidatation is to prepare for that and we're finally getting close.
Am 13.03.20 um 12:21 schrieb Christoph Hellwig: > On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: >> The non-page scatterlist is also a big concern for RDMA as we have >> drivers that want the page list, so even if we did as this series >> contemplates I'd have still have to split the drivers and create the >> notion of a dma-only SGL. > The drivers I looked at want a list of IOVA address, aligned to the > device "page size". What other data do drivers want? Well for GPUs I have the requirement that those IOVA addresses allow random access. That's the reason why we currently convert the sg_table into a linear arrays of addresses and pages. To solve that keeping the length in separate optional array would be ideal for us. But this is so a special use case that I'm not sure if we want to support this in the common framework or not. > Execept for the software protocol stack drivers, which of couse need pages for the > stack futher down. Yes completely agree. For the GPUs I will propose a patch to stop copying the page from the sg_table over into our linear arrays and see if anybody starts to scream. I don't think so, but probably better to double check. Thanks, Christian. > >> I haven't used bio_vecs before, do they support chaining like SGL so >> they can be very big? RDMA dma maps gigabytes of memory > bio_vecs itself don't have the chaining, but the bios build around them > do. But each entry can map a huge pile. If needed we could use the > same chaining scheme we use for scatterlists for bio_vecs as well, but > lets see if we really end up needing that. > >> So I'm guessing the path forward is something like >> >> - Add some generic dma_sg data structure and helper >> - Add dma mapping code to go from pages to dma_sg > That has been on my todo list for a while. All the DMA consolidatation > is to prepare for that and we're finally getting close.
On Fri, Mar 13, 2020 at 09:17:42AM -0300, Jason Gunthorpe wrote: > On Fri, Mar 13, 2020 at 04:21:39AM -0700, Christoph Hellwig wrote: > > On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: > > > The non-page scatterlist is also a big concern for RDMA as we have > > > drivers that want the page list, so even if we did as this series > > > contemplates I'd have still have to split the drivers and create the > > > notion of a dma-only SGL. > > > > The drivers I looked at want a list of IOVA address, aligned to the > > device "page size". What other data do drivers want? Execept for the > > software protocol stack drivers, which of couse need pages for the > > stack futher down. > > In principle it is possible to have just an aligned page list - > however the page size is variable, following certain rules, and today > the drivers still determine the correct page size largely on their > own. > > Some progress was made recently to consolidate this, but more is > needed. > > If the common code doesn't know the device page size in advance then > today's approach of sending largest possible dma mapped SGLs into the > device driver is best. The driver only has to do splitting. The point was that drivers don't need pages, drivers need IOVAs. In what form they are stuffed into the hardware is the drivers problem.
Am 16.03.20 um 09:56 schrieb Christoph Hellwig: > On Fri, Mar 13, 2020 at 09:17:42AM -0300, Jason Gunthorpe wrote: >> On Fri, Mar 13, 2020 at 04:21:39AM -0700, Christoph Hellwig wrote: >>> On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: >>>> The non-page scatterlist is also a big concern for RDMA as we have >>>> drivers that want the page list, so even if we did as this series >>>> contemplates I'd have still have to split the drivers and create the >>>> notion of a dma-only SGL. >>> The drivers I looked at want a list of IOVA address, aligned to the >>> device "page size". What other data do drivers want? Execept for the >>> software protocol stack drivers, which of couse need pages for the >>> stack futher down. >> In principle it is possible to have just an aligned page list - >> however the page size is variable, following certain rules, and today >> the drivers still determine the correct page size largely on their >> own. >> >> Some progress was made recently to consolidate this, but more is >> needed. >> >> If the common code doesn't know the device page size in advance then >> today's approach of sending largest possible dma mapped SGLs into the >> device driver is best. The driver only has to do splitting. > The point was that drivers don't need pages, drivers need IOVAs. In > what form they are stuffed into the hardware is the drivers problem. Well I would prefer if the drivers can somehow express their requirements and get IOVA structures already in the form they need. Converting the IOVA data from one form to another is sometimes quite costly. Especially when it is only temporarily needed. Regards, Christian.
On Mon, Mar 16, 2020 at 10:41:42AM +0100, Christian König wrote: > Well I would prefer if the drivers can somehow express their requirements > and get IOVA structures already in the form they need. > > Converting the IOVA data from one form to another is sometimes quite costly. > Especially when it is only temporarily needed. We basically have two ways to generate the IOVA: - a linear translation for the direct mapping case or some dumb IOMMU drivers - in that case case there is a 1:1 mapping between input segments and output segments in DMA mapping - a non-trivial IOMMU where all aligned segments are merged into a single IOVA range So I don't really see how the dma layer could help much with any limitation beyond existing max size and dma boundary ones.
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h index 6eec50fb36c8..28a477bf0bdf 100644 --- a/include/linux/scatterlist.h +++ b/include/linux/scatterlist.h @@ -145,6 +145,29 @@ static inline void sg_set_buf(struct scatterlist *sg, const void *buf, sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf)); } +/** + * sg_set_dma_addr - Set sg entry to point at specified dma address + * @sg: SG entry + * @address: DMA address to set + * @len: Length of data + * @offset: Offset into page + * + * Description: + * Use this function to set an sg entry to point to device resources mapped + * using dma_map_resource(). The page pointer is set to NULL and only the DMA + * address, length and offset values are valid. + * + **/ +static inline void sg_set_dma_addr(struct scatterlist *sg, dma_addr_t address, + unsigned int len, unsigned int offset) +{ + sg_set_page(sg, NULL, len, offset); + sg->dma_address = address; +#ifdef CONFIG_NEED_SG_DMA_LENGTH + sg->dma_length = len; +#endif +} + /* * Loop over each sg element, following the pointer to a new list if necessary */
This can be used by drivers to setup P2P DMA between device memory which is not backed by struct pages. The drivers of the involved devices are responsible for setting up and tearing down DMA addresses as necessary using dma_map_resource(). The page pointer is set to NULL and only the DMA address, length and offset values are valid. Signed-off-by: Christian König <christian.koenig@amd.com> --- include/linux/scatterlist.h | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)