On 2021/02/26 10:13, William Tu wrote:
On Thu, Feb 25, 2021 at 7:26 AM Toshiaki Makita
<toshiaki.maki...@gmail.com> wrote:
On 2021/02/24 3:37, William Tu wrote:
I don't know if this is too much to ask for.
I wonder if you, or we can work together, to add at least a tunnel
support, ex: vxlan?
The current version is a good prototype for people to test an L2/L3
XDP offload switch,
but without a good use case, it's hard to attract more people to
contribute or use it.
I think we have discussed this before.
Vxlan or other tunneling is indeed important, but that's not straightforward.
Push is easy, but pop is not. Pop requires two rules and recirculation.
Recirculation is highly likely to cause eBPF 1M insn limit error.
Recirculation is pretty important. For example connection tracking also
relies on recirc. Can we break into multiple program and tail call?
For recirc action, can we tail call the main ebpf program, and let the
packet goes through parse/megaflow lookup/action?
OK, will try using tail calls.
This will require vswitchd to load another bpf program for tail calls.
I guess such a program can be specified in main bpf program meta data.
I'll check if it works.
Do you know whether using bpf function call helps solving the
1M insn limit or stack limitation?
https://lwn.net/Articles/741773/
Looking at check_func_call() in verifier.c, it seems not.
IIUC, If we have a flow that requires executing multiple actions,
using bpf function call can save the stack size, but the total
instruction limit is still 1M.
When using tail call, we have more work to do to break into
individual ebpf program, but each program can have 1M insn
and stack size.
Yes I think tail calls do help.
But on the second thought, I think I should identify the verifier logic
which causes consumption of that many instructions. Then we can determine if
we have another option to mitigate that.
E.g. The problem happens around loops. Loop unrolling may help mitigating it or
not?
I thought the problem is loop unrolling?
Not really.
because of loop unrolling, the number of instructions increases a lot,
and might cause over 1M insn.
The problem is not the program size but the number of insns processed in the
verifier.
AFAICS through trial and error, it looks like adding branches outside loops does not
bloat insns processed in the verifier, but branches inside loops do.
I think the point is state pruning[1].
In fact the logic of state pruning looks more complicated inside loops[2].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f1bca824dabb
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2589726d12a1
Toshiaki Makita
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
