Question about map.increment() #bcc


Donald Hunter
 

On Sun, 25 Apr 2021 at 20:18, Y Song <ys114321@...> wrote:
This is a good question. In earlier bpf days, the key MUST be from
stack. Otherwise, the verifier will fail. Nowadays, things become
better and keys can be from verifier recognizable memory regions
(stack, key, value, allocated_mem, etc.). I think rewriter can be made
smart to check if the first argument of the increment is actually a
variable (instead of an expression), we can directly take the address
of it since the variable can be allocated on stack. The relevant code
is at b_frontend_action.cc. Do you want to take a look to see whether
you could help improve the bcc rewriter for this particular issue?
I am happy to take a look at the code and see if I can improve it at all.

Thanks,
Donald.


Yonghong Song
 

On Thu, Apr 22, 2021 at 4:18 AM Donald Hunter <donald.hunter@...> wrote:

Is there a reason why map.increment() internally copies the key into a stack variable? When building a key inline, it uses double the stack space and incurs the cost of a copy. For u64 keys this is fine but for larger custom keys, e.g. containing a char[] it blows up the stack pretty quickly.
This is a good question. In earlier bpf days, the key MUST be from
stack. Otherwise, the verifier will fail. Nowadays, things become
better and keys can be from verifier recognizable memory regions
(stack, key, value, allocated_mem, etc.). I think rewriter can be made
smart to check if the first argument of the increment is actually a
variable (instead of an expression), we can directly take the address
of it since the variable can be allocated on stack. The relevant code
is at b_frontend_action.cc. Do you want to take a look to see whether
you could help improve the bcc rewriter for this particular issue?


Thanks, Donald.


Donald Hunter
 

Is there a reason why map.increment() internally copies the key into a stack variable? When building a key inline, it uses double the stack space and incurs the cost of a copy. For u64 keys this is fine but for larger custom keys, e.g. containing a char[] it blows up the stack pretty quickly.

Thanks, Donald.