Hi,
Le 31/07/2019 à 09:11, Stephan Müller a écrit :
If I remember correctly, the implementation with vmsplice was slower by
a
factor of 10 compared to sendmsg on the ISO image on an x86 system.
At the time being I have an issue with this fix, because the talitos
driver only accepts 32k bytes at a time. With vmsplice, data is handed
over to the driver by blocks of PAGE_SIZE (16k in my case). With
sendmsg(), data is handed over to the driver with a single block.
Ok. But wouldn't your driver need to process the data in the chunk size
your hardware requires?
Sure it needs to process the data in the chunk size the HW requires, but
do you know if there is a way to tell the core than the driver doesn't
accepts chunks of more than 32kbytes, or shall the driver be able to
handle data of any size ?
Coming back to this: Were you able to find a fix?
As far as I know the problem still exists.
We want to upgrade libkcapi on our target, but still facing the issue
with libkcapi newer than 1.1.3 : When a file is bigger than 32 Kb,
hashing operation (md5 or sha256) fails and the kernel prints the
following message:
[ 2369.772999] talitos b0030000.crypto: length exceeds h/w max limit
Is there a way to tell crypto kernel core that a given driver has a
fixed limit and that data shall be sent in chunks ? Or is it the
responsibility of the driver to cut off the data in acceptable chunks ?
I guess the Talitos driver is not the only driver with such a limit, so
something centralised must exist to handle it ?
Thanks
Christophe
