On Thu, May 21, 2026 at 06:30:16PM +0200, Felix Maurer wrote: > Hi Daniel, > > I found your series because I was about to implement something similar > like your hashing implementation. In other words, I'd be very happy to > see this patchset move forward. > > Taking an initial look at your hashing patches, I'm wondering: the usual > interface to hash/digest algorithms is to have three functions: an > init() function to set up state
Doesn't bpf_crypto_ctx_create already provide the initialization? I was trying to make that pattern work by adding the bpf_crypto_type_id to make the code a little more maintainable. > an update() function that can be called multiple times to hash new > bytes, and a finalize() function that creates the actual hash. > Depending on the algorithm, some of them (esp. finalize) may be > no-ops. Often, a fourth function, like hash(), is provided I think the bpf_crypto_encrypt should cover that along with the bpf_crypto_hash in the first patch. > I think we should provide the same init/update/finalize interface in bpf > as well to make the API more flexible. That would require splitting out > the shash_desc from the (mostly static) context. But doing so would also > address the review comment from bpf-ci bot to patch 1. WDYT? I was trying to make things work with the existing bpf_crypto_ctx lifecycle. IIRC in the V1/V2 of the series there was a separate struct but it was suggested to integrate the changes into bpf_crypto_ctx. Regarding the bpf-ci bot I think it's somewhat valid, but you could solve that by putting the bpf_crypto_ctx in a per CPU map or protecting it with a bpf spinlock. I didn't hear back from the crypto folks so I sort of left things as is. If you want to give it a go feel free. It would also be helpful to hear about what your use case is. Thanks for taking a look! -Daniel
