The setup is pretty simple. There's an eno1 (igb driver), to which our default route points. On the same box are several VMs. There's a tap interface (for each VM, call it tapX). Traffic for a VM flows in from the Internet on eno1 and is directed to tapX; the response traffic flows in the other direction. I'm deliberately simplifying here: eno1 runs an XDP program that does some lightweight IP rewriting from anycast addresses to internal VM addresses on ingress. eno1's XDP program currently XDP_PASS's rewritten packets to the IP stack, where they're routed to the VM's tap. This works fine. tapX runs an XDP program that does the same rewriting in reverse. Right now, it also XDP_PASS's packets to the stack, which also works --- the stack routes response traffic out eno1. I'm playing with XDP_REDIRECT'ing instead of XDP_PASS'ing. I have the ifindexes and MAC addresses (and those of IP neighbors) in a map --- a normal HASH map, not a DEVMAP. Using that map, I can successfully redirect traffic from tapX to arbitrary other tap interfaces. What I can't do is redirect packets from tapX to eno1, which is what the system actually needs to do. --- Thomas H. Ptacek On Fri, Sep 18, 2020 at 5:21 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Thomas Ptacek <thomasptacek@xxxxxxxxx> writes: > > > Weird question: > > > > Should there be a reason for me to expect bpf_redirect to fail when > > redirecting, in XDP, to the egress of an xdpgeneric device? > > What does 'the egress of an xdpgeneric device' mean, exactly? I.e., > could you share some more details of your setup, please? > > In general, mixing native and generic mode XDP is not likely to work > well... > > -Toke > -- --- Thomas H. Ptacek 312-231-7805