On 5/18/20 3:38 AM, Lorenz Bauer wrote: > On Fri, 15 May 2020 at 15:24, David Ahern <dsahern@xxxxxxxxx> wrote: >> >> On 5/15/20 3:59 AM, Lorenz Bauer wrote: >>> >>> Yes, but that doesn't play well with changing the source address to >>> the local machine's, since the upper part of the stack will drop the >>> packet due to accept_local=0. >> >> Can you defer the source address swap to the Tx path? Let the packet go >> up the stack and do the fib lookup again as an skb. neighbor entry does >> not exist, so the packet is stashed, neighbor resolution done, once >> resolved the packet goes out. tc program on the egress device can flip >> the source address, and then subsequent packets take the XDP fast path. > > Hm, that's an interesting idea! I guess this means I have to mark the packet > somehow, to make sure I can identify it on the TX path. Plus, in theory > the packet could exit via any interface, so I'd have to attach classifiers to > a bunch of places if I want to be on the safe side. Shared blocks might save you some overhead. Create a filter block that is shared across devices. > > Upside: this seems doable in current kernels. Downside: seems more fragile > than I'd like. > > Thanks for the thought, I'll play around with it :) > >> >> If the next host is on the same LAN I believe the stack will want to >> generate an ICMP redirect, but that can be squashed. >
