operations through Linux's AF_ALG interface. It makes a big difference on
reduced resource environments, like ARM.
For example, ARM architectures with the Kirkwood hardware crypto support
chip (with appropriate kernel extensions enabled), can hash SHA1 at 70MB/s
by calling into the kernel with AF_ALG sockets, whereas the Go stdlib on
the same ARM chip can do about 5 MB/s.
It's actually pretty simple to set up, but it left me with a couple of
questions about holes in the syscall standard library.
Specifically - I'm wondering what the Go community's opinion would be of me
pushing patches to the syscall library that do any subset of these things:
1) add support for a sockaddr_alg type on Linux.
2) add support for a generic raw sockaddr type that can actually be used by
source outside of the syscall package.
3) provide a version of accept that does not return or ask for a sockaddr,
or alternatively, does, but doesn't fail if it doesn't understand the type.
4) add the send() call.
5) extend the sendto() call to allow a nil sockaddr.
The motivation for the above requests is documented in comments in the
above implementation link. As I said before, that link can get 14x faster
throughput on SHA1 operations on my ARM device (after patching my kernel
with Phil Sutter's mv_crypto DMA extensions). The AF_ALG interface the
kernel supports is of course not at all restricted to SHA1. It can do all
sorts of encryption, hashing, and other crypto operations. SHA1 is
currently my motivating example.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.