Date: Mon, 1 Mar 2010 12:19:26 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: "Kennedy, Brendan" <brendan.kennedy@intel.com> Cc: "Philip@freebsd.org" <Philip@freebsd.org>, "freebsd-drivers@freebsd.org" <freebsd-drivers@freebsd.org> Subject: Re: [PATCH] patch to OpenCrypto framework Message-ID: <20100301201926.GG1293@michelle.cdnetworks.com> In-Reply-To: <CFBC532374C38D45810FA00BC2D2C2042544A1@irsmsx502.ger.corp.intel.com> References: <CFBC532374C38D45810FA00BC2D2C2041FB949@irsmsx502.ger.corp.intel.com> <20100227225228.470e9b7b@davenulle.org> <CFBC532374C38D45810FA00BC2D2C2042543E7@irsmsx502.ger.corp.intel.com> <20100301181444.GA1293@michelle.cdnetworks.com> <CFBC532374C38D45810FA00BC2D2C2042544A1@irsmsx502.ger.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 01, 2010 at 08:08:54PM +0000, Kennedy, Brendan wrote: > > >-----Original Message----- > >From: Pyun YongHyeon [mailto:pyunyh@gmail.com] > > > >> I think it is best to do this check at allocation time, rather than > >forcing drivers to do it. It would be a serious overhead for them to > >have to do another allocation and memory copy in the data path. > >> > > > >If hardware can handle non-contiguous memory region, this change > >may add more overheads to those hardwares. Couldn't this be > >handled in hardware driver? > > Hmm, when it comes to memory allocations and data copies, the less that are done in the data path the better! > Not adding code to handle this case outside drivers could end with vendors having to patch supported frameworks as best they can. > > Another way would be for drivers to support breaking virtually contiguous memory into scatter gather lists of physically contiguous memory before sending to hardware. I believe bus_dma(9) can handle this. New drivers should always use bus_dma(9). > It sounds like something that could be done from a kernel function, but I'm not sure what the overhead would be vs contigmalloc (probably less overhead and maybe sturdier when there's a high level of memory fragmentation). > It may depends on hardware. If hardware support multiple DMA read for SG list, there would be no overhead at all. bus_dma(9) has slight overhead but most cases it's negligible, I think. > > I guess cheap hardware may have other > >limitation as well(alignment restrictions, size limitation etc). > >Just changing contigmalloc(9) wouldn't solve other limitation of > >hardware. > > Changing the kernel based on the possibly lesser capabilities of some hardware is probably not a good idea. > However I think most external hardware drivers have to handle the issue of non contiguous physical memory in some way. > I agree, this is the reason why I think handling some limitation in driver would be better thing. As I said, bus_dma(9) can take care of non contiguous physical memory limitation of hardware. > >Alternatively can we add some capability flag to driver such that > >framework can do required action(contigmalloc or malloc) based on > >the capability? > > > > That sounds like a good method! > > Best Regards, > Brendan > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100301201926.GG1293>