Ralf Lici [off-list ref] writes:

This commit introduces the core start_xmit processing flow: validate,
select action, translate, and forward. It centralizes action resolution
in the dispatch layer and keeps per-direction translation logic separate
from device glue. The result is a single data-path entry point with
explicit control over drop/forward/emit behavior.

Signed-off-by: Ralf Lici <redacted>

This is very cool! Going quickly through the series, this seems like
thorough work that will be cool to have available in the kernel, so
thanks for doing this! I'll be quite happy to retire my barebones
BPF-based implementation once this lands :)

One comment on the device model below (which is also why I chose this
patch to reply to):

+static void ipxlat_forward_pkt(struct ipxlat_priv *ipxlat, struct sk_buff *skb)
+{
+	const unsigned int len = skb->len;
+	int err;
+
+	/* reinject as a fresh packet with scrubbed metadata */
+	skb_set_queue_mapping(skb, 0);
+	skb_scrub_packet(skb, false);
+
+	err = gro_cells_receive(&ipxlat->gro_cells, skb);

So given that you're not resetting skb->dev here, IIUC, this means that
the translated packet will magically re-appear as if it arrived on the
interface it first came in on, right?

That seems... a bit too magical? Sending a packet to one device making
it suddenly reappear on a different, unrelated, device seems like it
will just create confusion. It's like the ipxlat device can't really
device if it's a device or a tunnel? :)

I think a better model is to treat the device as basically a loopback
device that translates packets before looping them back (so when they
come back they appear to be coming from that device).

Any reason why that wouldn't work?

-Toke