The encap helpers are currently enabled if ENCAP_IFINDEX is available. For
XDP we can't redirect to the encap interface, so we don't want visibility
of the actual ifindex. But we still want to call into the common helper
infrastructure from generic code (ie. nodeport.h).

So add a HAVE_ENCAP macro to decide whether we need the encap helpers, and
hide the tunnel-key details in an skb-specific helper. The XDP variant
should not be called by anyone yet.

Signed-off-by: Julian Wiedmann <jwi@isovalent.com>

When redirecting a packet to the encap iface, set the target ifindex in the
ctx-specific part of the code path. This avoids exposing the ENCAP_IFINDEX
to XDP programs (where it can't be used), and in the future allows us to
redirect to an arbitrary interface (eg. if XDP already added the encap
headers manually).

Signed-off-by: Julian Wiedmann <jwi@isovalent.com>

Callers of __encap_with_nodeid() currently assume that they can redirect
the packet afterwards. Make this explicit by returning CTX_ACT_REDIRECT,
and having the immediate callers handle it.

This later allows us to return CTX_ACT_OK from XDP context, and have the
caller pass the packet to the stack instead - like we do for IPSec today.

In the high-level paths, it's enough to teach the rev_nodeport_*() parts in
nodeport.h about CTX_ACT_OK. All the other callers are certainly skb-only,
and some already know how to handle CTX_ACT_OK as they enter through an
IPSec-enabled path.

Signed-off-by: Julian Wiedmann <jwi@isovalent.com>

Our XDP and TC programs use custom areas to store their metadata
(XDP uses a per-CPU scratchpad, TC uses __sk_buff->cb[]). So when XDP
passes a packet up to TC, we explicitly need to copy any relevant metadata
into xdp_md->data_meta.

Extract a helper for this copy operation, so that it can be easily called
from shared code.

Also extend ctx_get_xfer() so that the TC layer can access additional
xfer data.

Signed-off-by: Julian Wiedmann <jwi@isovalent.com>

When XDP needs to tunnel-encap a packet, pass it up the stack and redirect
it to the tunnel interface from the netdev's TC ingress. In contrast to a
pure XDP solution, this lets us re-use all the existing tunnel
infrastructure in the kernel and host.

Achieve this by having ctx_set_encap_info() store the tunnel information
into our internal metadata, and transfer it over when going from XDP to TC.

For now we only use this for the case of EgressGW reply traffic - so the
change in tail_rev_nodeport_lb6() is just for commonality, we never hit the
ret != CTX_ACT_REDIRECT case there.

But it should be possible to extend this for the general case of running
XDP with TUNNEL_MODE. The relevant code paths just need to learn how to
handle CTX_ACT_OK and CTX_ACT_REDIRECT return values when calling encap
helpers.

Note that if all the xfer data becomes too much, we can probably also just
have a second tunnel look-up in cil_from_netdev() to get all that stuff.

Fixes: cilium#19717
Fixes: cilium#19624
Signed-off-by: Julian Wiedmann <jwi@isovalent.com>

Add a combination with Nodeport-Acceleration, Direct-Routing and EgressGW.

Also move ENABLE_EGRESS_GATEWAY into the MAX_BASE_OPTIONS, so that
MAX_XDP_OPTIONS can pick it up.

Signed-off-by: Julian Wiedmann <jwi@isovalent.com>

Test the new EgressGW functionality in XDP, which flags EgressGW reply
packets that need to go via the tunnel so that TC-Ingress can redirect
them.

Signed-off-by: Julian Wiedmann <jwi@isovalent.com>