[PATCH] patch to OpenCrypto framework

[Kennedy, Brendan]

>-----Original Message-----
>From: Pyun YongHyeon [mailto:pyunyh at 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.
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).

> 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.

>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.