Date: Mon, 22 Jan 2001 15:14:30 -0600 From: Robert Lipe <robertlipe@usa.net> To: Alfred Perlstein <bright@wintelcom.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122151430.R10504@rjlhome.sco.com> In-Reply-To: <20010122125444.C26076@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jan 22, 2001 at 12:54:44PM -0800 References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@fw.wintelcom.net> <20010122132647.I10504@rjlhome.sco.com> <20010122121033.A26076@fw.wintelcom.net> <20010122145550.O10504@rjlhome.sco.com> <20010122125444.C26076@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > there's a problem because there's no busdma for mbufs (well > > > actually there is but it fails on really small unaligned blocks > > > which basically breaks it for mbufs). > > > > Can you tell me more about this hazard? I can't control the > > alignment that's asked for by the driver, but I can certainly fudge > > the size and alignment of the request by the time it gets to this > > interface. Just tell me the rules. :-) > > I don't know, Bill Paul explained that the normal busdma stuff is > pretty broken for chunks too small. Basically, disks work, network > cards won't because mbufs are too small. Ouch. That's a problem. Of course, one of the goals of UDI is to provide a consistent API into this sort of stuff. We don't distinguish at the driver level between disk buffers and network buffers. Ideally, the underlying DMA code really wouldn't know (or have to care) what type any of this is. If busdma is "pretty broken" for network-sized requests, I may just avoid it for now, implement the contigmalloc cache, and move on to more interesting problems. RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010122151430.R10504>