With the emergence of TP 4091 for NVMe, eBPF can be used to offload programs to computational storage processors.
This change introduces the possibility of overriding the default stack size of 512 bytes for non-kernel runtime environments.
Details
- Reviewers
ast yonghong-song eddyz87 - Commits
- rG6ee6b197f5cd: Make BPF stack size overridable
Diff Detail
Unit Tests
Time | Test | |
---|---|---|
40 ms | x64 debian > LLVM.CodeGen/BPF::undef.ll |
Event Timeline
Hello Alexei,
I appreciate your prompt attention. Determining the maximum stack size is difficult, but a reasonable estimate could be an increase of two orders of magnitude.
We developed a computational storage processor at the IT University of Copenhagen that executes eBPF programs. During our evaluation of loop versus loop-unrolling performance on hardware, we discovered that the stack is easily prone to exhaustion and that kernel characteristics no longer apply when executing on hardware.
We plan on conducting additional research to comprehend the characteristics of eBPF on computational storage.
I removed the llvm namespace since it is already known through the using statement.
I furthermore made the parameter unsigned since a stack will never be negative.
Sorry for the revision spam.
It looks like using an unsigned integer had adverse effects on the tests. I am reverting to signed integers but keeping the namespace change.
Thanks for the review. I have a colleague at the IT University of Copenhagen doing a PhD on program verification for computational storage. However, for now, it's an open question.
We do some runtime checks, but the real issue is that when compiling BPF for computational storage, the device characteristics (stack size, helper functions, etc.) are unknown. As such, the verification must happen on the device, and the question is how we efficiently do that and how we convey potential verification problems back to the host.
Okay, thanks for explanation. The patch certainly okay as it doesn't change the current default funcitonality. Not exactly sure how the decide will verifier the program but that is a separate issue.
Sorry, since Yonghong and Alexei commented on this diff I hadn't thought that my "accept" is necessary.
The diff seem to be fine.
Hi Eddy. Thanks for the review! I assume your review was the thing @ast was waiting for. Now we can get it merged!
Could you please update your profile with email, so that I can set commit author? (or ping me at eddyz87@gmail.com).
I'm following this guide and it suggests setting authors name + email, also commit history suggests that this is the norm.
There should already be an e-mail on my profile. If you can't see it, here's the info.
Niclas Hedam <niclas@hed.am>