-
Notifications
You must be signed in to change notification settings - Fork 26
workaround for hitting BPF max stack size #43
Comments
How about declaring hd as volatile? |
then it uses only 136 byte |
That is weird, you would not expect this program to be so large. Maybe you can play more with volatile; perhaps instead of a second structure hd__ you can just use a volatile pointer to hd and use to make a read between the parser and the deparser. |
OK. |
I actually like the generated with volatile. With volatile, the compile spills the ethernet src/dst to stack using 1 byte instead of 8 byte, so it uses much less stack. However, there is no reordering at all, it's easier to read, but maybe have some performance overhead? At lease when reading out the hd.x.y, it will read it from the stack and with the right size (no longer fixed to 8 byte). Now I suspect there might be an issue in verifier. |
Hi,
But when I add volatile before struct Headers hd in the xdp7.c , it would be no problem to load. |
@williamtu did you find the suitable solution for this problem ? We're also facing it in our uBPF backend. The |
I declare another "struct Headers hd__" at the deparser code block, so that the live range of "hd" is reset at deparser.
An example of using xdp7.p4, before the patch, we use 616 byte stack memory
What do you think?
The text was updated successfully, but these errors were encountered: