Linux's header here uses 'chacha20poly1305_*' as the prefix instead of 'chacha20_poly1305_*. We use underscores in all the other places (cryptodev.h, etc.) in FreeBSD though.

Also, Linux's API apparently doesn't support 12 byte nonce's (as used by TLS/IPsec) as it takes a uint64_t for the nonce instead of an array of bytes. An array of bytes is more consistent with how we treat nonce/IV's in the rest of the crypto code however.

Note that my other series I uploaded that adds multi_block encrypt/decrypt would be applicable here and in other places in this file. I have a followup change in my branch that replaces these loops with a single call to the multi-block variants. If multi-block lands first I will probably squash that into this change.

src_len, aad_len and nonce_len could perhaps be defined const. That'd be another deviation from the Linux interface, I guess, but hopefully not an incompatible one?

Shouldn't this be adding resid instead of src_len?

I guess it should technically be XCHACHA20_POLY1305_KEY.

I don't know that making size_t arguments passed by value const buys a whole lot, but it should be fine to do (and shouldn't be a meaningful API change relative to Linux as the caller doesn't care, the const only impacts the implementation)

Yes, this is a leftover from an earlier version that modified src_len rather than having a local resid.

I think resid % POLY1305_BLOCK_LEN != 0 is always true here, since we know resid > 0 and resid < CHACHA20_NATIVE_BLOCK_LEN.

Not necessarily. CHACHA20_NATIVE_BLOCK_LEN is 64 whereas POLY1305_BLOCK_LEN, so resid values of 16, 32, and 48 would make this false.