Mihai Budiu

This should be much slower. We should be able to figure out what the problem with the stack is.

So we know that stack usage is not the problem.

How about you just run the preprocessor and look at the generated C?

Actually it can't be the load_byte - that's the load. The store is the problem.

This looks like a bug in the bpf llvm back-end bug. If you look at the assembly, they always write a double-word (64 bits) no matter what the output type...

For example, I changed the source to be just an u8, and the code generated is this: .loc 2 89 37 # xdp7.c:89:37 std -464(r10), r1 ldb r1, 0(r2) As...

I found a workaround this problem: if you take the address of the headers struct the compiler has to put it on the stack. So I just added this: printk("%p",...

In which way does it not work as you want?

Unfortunately I don't think there's anything we can do. You should bring this up at the iovisor summit.

This issue and #22 are really the same thing.