On Sun, 11 Oct 2020 20:50:12 -0600 David Ahern <dsahern@xxxxxxxxx> wrote: > On 10/11/20 10:16 AM, Daniel Borkmann wrote: > >> > >> This is awesome results and great work Daniel! :-) > > +1 > > >> > >> I wonder if we can also support this from XDP, which can also native > >> redirect into veth. Originally I though we could add the peer netdev > >> in the devmap, but AFAIK Toke showed me that this was not possible. > > > > I think it should be possible with similar principle. What was the > > limitation that you ran into with devmap for XDP? If you add a device to devmap and afterwards move this device into a namespace, then the device is removed from the devmap. This is because devmap detect/react on NETDEV_UNREGISTER and remove the net_device. > Should just need an API to set the namespace of the redirect device - > something that devmap can be extended to include now. Perhaps for other devices being moved into a namespace. Specifically for veth the XDP redirect (veth_ndo_xdp_xmit) already pickup the peer net_device, and *queue* the xdp_frame, thus it's not directly relevant for the XDP redirect (except we also have an intermediate queue which is likely bad for the TCP_RR test). I just tried to test native-XDP redirect into a veth with samples/bpf/ xdp_redirect_map, which doesn't work. Packets are actually getting silently dropped. After digging into the kernel code, I realized this is because the *peer*-veth device didn't have a XDP-prog loaded. The xdp_redirect_map loads a dummy-XDP prog on the veth-device (it can see), as a way to enable the ndo_xdp_xmit (which we have discussed before it a broken way to do this, but it have become a defacto way). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
