On December 29, 2017 1:29:59 AM PST, Jesper Dangaard Brouer <brouer@xxxxxxxxxx> wrote: >On Thu, 28 Dec 2017 21:19:26 -0800 >Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > >> On December 28, 2017 8:34:24 PM PST, David Ahern <dsahern@xxxxxxxxx> >wrote: >> >On 12/28/17 9:37 PM, MD I. Islam wrote: >> >> Hi >> >> >> >> Is XDP designed for implementing packet forwarding? Is there an >> >> example of ipv4 forwarding the kernel? I don't find any example in >> >> samples/bpf/ directory. >> > >> >samples/bpf/xdp_router_ipv4_*.c >> > >> >I have a POC on using new helpers that allow BPF programs to >leverage >> >kernel FIB and neighbor tables: >> > https://github.com/dsahern/linux/commits/bpf/xdp-fwding-wip >> > >> >It shows a 400% increase in forwarding. A lot of issues need to be >> >addressed, but it shows the intent. >> >> Nice! What would be uber cool is a NATP fastpath implemented using >> XDP. Now that eBPF for ARM32 has landed it would enable a lot of >> platforms. > >Yes, and we will get there. Once the OpenWRT/LEDE drivers actually >implement XDP support in their drivers ;-). And more drivers support >XDP_REDIRECT. > >That said, I would not recommend (re)implementing a NAT fastpath in >XDP. >It is doable, but will require an advanced eBPF prog that keep state >(via maps) etc. For now I recommend falling back to Netfilter NAT for >this purpose. Pure routing (no NAT) on a embedded device could be >accelerated a lot with this approach. > >Instead of trying to re-implementing everything in XDP, I instead want >you/people to think about how XDP can cooperate with and >software-offload part of the Linux network stack. > This is exactly what samples/bpf/xdp_router_ipv4_*.c and David Ahern >is doing. Notice that these solutions leverage the existing IPv4 >routing table for lookups, which means that all existing tools remains >the same, while XDP can software-offload and accelerate the basic IPv4 >routing step. It is important to limited the scope, IMHO advanced >routing (e.g. with multiple route-tables, ToS match/routing etc) should >fallback to the normal Linux network stack, and not be handled by XDP. Sure, I am not thinking about reimplementing everything, just trying to leverage XDP where and when it makes sense to avoid lots of cache trashing per packet on devices that already pathologically suffer from small I and D cache sizes. The goal would be to leverage the existing nefilter infrastructure and use it, not replace it or supplement it. With Pablo's latest flow offload work, I would be expecting the higher end devices that feature HW NATP to be finally supported, but there are still lower end devices for which none of that exists, and where a SW fastpath using XDP would be great to have, for routing and not just that. Thanks -- Florian
|