Date: Tue, 04 Sep 2012 17:57:42 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test Message-ID: <1346803062.59094.27.camel@revolution.hippie.lan> In-Reply-To: <CAJ-VmonnaPE=6SVvc1hDE2URAY9TSWkMXOwa7F4X2knBQgbxNw@mail.gmail.com> References: <1346777897.1140.633.camel@revolution.hippie.lan> <CAJ-VmonnaPE=6SVvc1hDE2URAY9TSWkMXOwa7F4X2knBQgbxNw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2012-09-04 at 15:37 -0700, Adrian Chadd wrote: > Hiya, > > This is pretty neat work. :) > > But by converting drivers to use individual uma allocations, aren't > you risking fragmenting FIFO rings and such? I'm sure there are > platforms out there whose memory controllers operate on minimum sized > bits (say, 512 byte chunks for some intel PC chipsets, if I'm not > mistaken) .. right now ath(4)'s RX descriptors are almost always kept > in order of allocation, but with your proposal it's quite possible > they'll be spread all around the the (fixed size) UMA slab. > I'm not quite sure I understand what you mean by that. Or rather, I'm not sure I understand the downside to a bunch of individual descriptors being scattered around in memory. If the hardware treats the descriptors as a linked list, it shouldn't matter where they're scattered. If it treats them as an array, then the only option is to allocate a single chunk of memory to hold the whole array, isn't it? In either case, what to do with the busdma sync ops when working with lists or arrays of descriptors that are shared between the CPU and a controller that accesses the same memory independently... well, that's something that's not directly addressed by this set of changes. If the CPU and the hardware are accessing the memory truly concurrently (such as what happens with a usb host controller), the current busdma code and documentation doesn't really address that. We need more discussion on that, but when I approached the topic in the freebsd-arch thread last week, the discussion fizzled out. We'll have to get back to it eventually. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1346803062.59094.27.camel>