On Mon, Jul 11, 2016 at 05:56:07PM -0700, Sargun Dhillon wrote: > It would be nice to have eBPF programs that are longer than 4096 > instructions. I'm trying to implement XSalsa20 in eBPF, and > unfortunately, it doesn't fit into 4096 instructions since I'm > unrolling all of the loops. Further than that, doing tail calls to > process each block results in me hitting the tail call limit.
a cipher in bpf? wow. that's pushing it :) we've been discussing various way of adding 'bounded loop' instruction to avoid manual unrolling, but it will be still limited to the 4k instruction per program, so probably won't help this use case. Are you trying to do it in the networking context? > It don't think that it makes much sense to expose the crypto API as > BPF helpers, as I'm not sure if we can ensure safety, and timely > execution with it. I may be wrong here, and if there is a sane, safe > way to expose the crypto API, I'm all ears. we had the patches to connect crypto api with bpf, but they were too hacky to upstream, since then we redesigned the approach and the latest should be much cleaner. The keys will be managed through normal xfrm api and bpf will call into crypto with mechanism similar to tail-call. The program will specify the offset/length within the packet to encrypt/decrypt and next program to execute when crypto operation completes. Root only for xdp and tc only. > Other than that, it would be nice to make the max instructions a knob, > and I don't think that it has much downside, given it's only checked > on load time. It would be nice to make the tail call limit a tunable > as well, but I'm unsure of the performance impact it might have given > that it's checked at runtime. > > What do y'all think is reasonable? Make them both tunable? Just one? None? It is preferred to achieve the goal without introducing a knob. Also sounds like that increasing 4k to 8k won't really solve it anyway.
