Any desire for a more flexible bus_dmamem_alloc variant ?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Any desire for a more flexible bus_dmamem_alloc variant ?

Jason Harmening
Hi everyone,

It's really bugged me for years that bus_dmamem_alloc() just uses the
tag's maximum size instead of allowing a size to be passed in.  I got
reminded of this again recently when looking over some busdma code.

I know others have voiced this complaint in the past:
https://lists.freebsd.org/pipermail/freebsd-current/2012-July/035281.html

I used to work on an out-of-tree driver that could've benefited from
something like this.  It also seems like the benefits of using
bus_dmamem_alloc() to always do the optimal thing instead of, say,
rolling your own using kmem_alloc_[attr|contig] will increase as we
adopt support for IOMMUs.

I'd like to see if there's any interest in adding a
bus_dmamem_alloc_attr() KPI that takes both a size and vm_memattr_t.
Are there any potential in-tree consumers of such a thing?

--Jason

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Any desire for a more flexible bus_dmamem_alloc variant ?

John Baldwin
On 2/10/19 1:13 AM, Jason Harmening wrote:

> Hi everyone,
>
> It's really bugged me for years that bus_dmamem_alloc() just uses the
> tag's maximum size instead of allowing a size to be passed in.  I got
> reminded of this again recently when looking over some busdma code.
>
> I know others have voiced this complaint in the past:
> https://lists.freebsd.org/pipermail/freebsd-current/2012-July/035281.html
>
> I used to work on an out-of-tree driver that could've benefited from
> something like this.  It also seems like the benefits of using
> bus_dmamem_alloc() to always do the optimal thing instead of, say,
> rolling your own using kmem_alloc_[attr|contig] will increase as we
> adopt support for IOMMUs.
>
> I'd like to see if there's any interest in adding a
> bus_dmamem_alloc_attr() KPI that takes both a size and vm_memattr_t.
> Are there any potential in-tree consumers of such a thing?

I have this review I need to rebase and write the manpage bits for.  While
it still ties the the size to the tag, it mostly hides the individual tag:

https://reviews.freebsd.org/D5704

--
John Baldwin

                                                                            
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Any desire for a more flexible bus_dmamem_alloc variant ?

Jason Harmening
On Mon, Feb 11, 2019 at 9:34 AM John Baldwin <[hidden email]> wrote:

> On 2/10/19 1:13 AM, Jason Harmening wrote:
>
> I have this review I need to rebase and write the manpage bits for.  While
> it still ties the the size to the tag, it mostly hides the individual tag:
>
> https://reviews.freebsd.org/D5704


I like that.  It doesn't fix my idealogical gripe about maxsize being a
constraint vs. an allocation specifier.
But I'm not sure that matters if it can get rid of most/all of the
practical ramifications of the problem.  Plus it kills off a bunch of other
cruft too.

Suggestion, maybe dumb: What if you added a flex array of segments at the
end of struct bus_dmamem and a maxsegs argument in the args struct to allow
multi-seg allocations?
That would fix what might be the only real impediment to using this pretty
much anywhere.


>
>
> --
> John Baldwin
>
>
>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"