On Thu, Feb 25, 2021 at 7:26 AM Toshiaki Makita
<[email protected]> 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?
because of loop unrolling, the number of instructions increases a lot,
and might cause over 1M insn.
William
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
