Sophia Yoo <sy6@xxxxxxxxxxxxx> writes: >> >> So this has nothing to do with the support in the driver; XDP is simply >> >> not suitable for what you're trying to do. Why are you trying to do this >> >> in the first place? I.e., what's the higher-level use case here? > >> > The higher-level design goal (simplified to what's relevant) is that I >> > am trying to perform a TCP 3WHS between the kernel network stack and >> > my xdp ingress/tc egress hooks, where some trigger on xdp ingress >> > sends a SYN packet to the network stack, and when the network stack >> > returns a SYN-ACK packet the egress program redirects the packet to >> > the ingress interface, where the XDP program converts the packet to an >> > ACK packet, then completing the handshake with the network stack. > >> It's trying to handshake with itself (on the same box)? Why? Is this a >> real use case, or a test for something else? If the latter, have you >> considered using a veth pair in going to a different namespace (that >> gets the "direction" right)? > > This is a real use case as part of a larger design I am working on. > However, given that redirect from TC egress to XDP_DRV_MODE ingress > fundamentally doesn't work, I am rethinking other options to the > design. Alternatively, it seems that support for XDP_REDIRECT from > egress to ingress is currently in the works, although I don't believe > the patch has yet been applied to the mainstream kernel. Huh, really? Haven't seen that, got a link? > So I will also try building the kernel myself with the patch and > hopefully get the egress to ingress redirect working with 2 XDP > programs attached in driver mode. Thank you very much for all your > help! You're welcome :) -Toke
|