> >>> 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/ 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. William _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
