On-stack allocation of DMA S/G lists

[Ian Lepore]

On Wed, 2012-08-08 at 07:25 +1000, Peter Jeremy wrote:
> On 2012-Aug-07 10:09:42 -0600, Ian Lepore <freebsd at damnhippie.dyndns.org> wrote:
> >And just for the record, looking at the problem from an even more
> >distant vantage... is there really a problem with stack-allocating the
> >segments?  On a 64-bit arch the struct is like 16 bytes.  Typical usage
> >is to allocate a tag allowing 1 or just a few segments.  Is anyone
> >really going to create a tag specifying hundreds of segments that would
> >overflow the stack?
> 
> The example that led me to study the code was drm(4).  Video cards
> typically require fairly large allocations (32MB in my case) but don't
> require the RAM to be contiguous - ie it created a tag with 8192
> segments in my case.  This may not be relevant to most arm or mips
> hosts but drm(4) is MI code that can (theoretically) be built on these
> architectures and is a real example where a tag can have many
> segments.
> 
> >  If they try, wouldn't failing the tag create be good enough?
> 
> No.  The caller specifies the hardware limits for the device.  They
> should not need to take into account implementation details that
> mean the full hardware capabilities are not needed.  We don't fail
> a tag create if it specifies that RAM above 4GB can be used when
> we don't have any.  Why should be fail a tag create that allows the
> use of up to 8192 tags when we only support 1?
> 

Oh, good example.  I was wondering if there was any realistic need for
lots of segments, and a big video buffer is exactly that.

-- Ian