Re: [RFC net-next 08/15] ipxlat: add translation engine and dispatch core

[Ralf Lici]

Hi Toke,

On Thu, 04 Jun 2026 20:23:51 +0200, Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
> Ralf Lici <ralf@xxxxxxxxxxxxx> 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 <ralf@xxxxxxxxxxxxx>
>
> 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 :)
>

Thanks, glad to hear this looks useful. I have not had much time to work
on ipxlat lately, but I hope to respin the RFC soon.

> 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? :)
>

That's not quite what happens in the routed xmit path. There the stack
sets skb->dev to the selected output device before handing the skb to
the device. For IPv4 and IPv6 this happens in ip_output/ip6_output,
where the output device is taken from the skb dst. So when the route
selects the ipxlat device, the skb reaches ndo_start_xmit with skb->dev
already pointing at the ipxlat device, not at the original ingress
device.

The internal 4-to-6 pre-fragmentation path should preserve the same
property as well: ip_do_fragment copies the skb metadata to the
generated fragments, including skb->dev, and the temporary dst used for
that path also points at the ipxlat device. The fragment callback then
feeds those fragments back into the same ipxlat processing path.

That said, I agree that relying on this implicitly is not great.
gro_cells_receive uses skb->dev directly, and the intended receive-side
re-injection model should be obvious at the call site. I will set
skb->dev = ipxlat->dev explicitly before gro_cells_receive in the next
version.

> 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?
>

That's indeed the intended model for the ipxlat netdevice: route packets
to it, translate them, then loop them back into the stack as packets
received from that same device. That seemed like the simplest model and
the one that exposes the translation point most clearly.

Thanks for your feedback!

-- 
Ralf Lici
Mandelbit Srl