On Fri, Sep 7, 2018 at 1:40 PM, Mauricio Vasquez <mauricio.vasq...@polito.it> wrote: > > I read the Joe's proposal and using that for this problem looks like a nice > solution. > > I think a good trade-off for now would be to go ahead with a queue/stack map > without preallocating support (or maybe include it having always in mind > that this issue has to be solved in the near future) and then, as a > separated work, try to use Joe's proposal in the map helpers. > > What do you think?
the problem with such approach is that it would mean that non-prealloc stack/queue api will be different from future one after verifier will get smarter. The alternative would be to support by-value api only. Meaning let stack/queue support value_size = 1,2,4,8 byte only. Then bpf_push|pop_elem() helper will be by-value instead of returning a pointer. No rcu callback issues and implementation on the kernel side can be much simpler. I think simple array of value_size elems with head/tail indices will be enough. Once we have Joe's verifier improvements we can add alloc/free bpf object management facility and use 8-byte stack/queue mapas a stack of pointers. I think decoupling memory operations alloc/free from stack push/pop would be additional benefit of such design.
