RE: [EXTERNAL] [PATCH] netpoll: support sending over raw IP interfaces

From: Ratheesh Kannoth
Date: Mon Mar 18 2024 - 10:07:44 EST


> From: Mark <mark@xxxxxxxxxx>
> Sent: Monday, March 18, 2024 5:13 PM
> To: Ratheesh Kannoth <rkannoth@xxxxxxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx; Hans de Goede <hdegoede@xxxxxxxxxx>; Eric
> Dumazet <edumazet@xxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Breno
> Leitao <leitao@xxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; David S.
> Miller <davem@xxxxxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: Re: [EXTERNAL] [PATCH] netpoll: support sending over raw IP
> interfaces
>
>
> Hi Ratheesh,
>
> > Op 14 mrt 6 Reiwa, om 03:46 heeft Ratheesh Kannoth
> <rkannoth@xxxxxxxxxxx> het volgende geschreven:
> >
> >> From: Mark <mark@xxxxxxxxxx>
> >> […]
> >
> > Hmm. That is not my question. Let me explain it in detail. Netconsole is
> using netpoll_send_udp() to encapsulate the msg over
> > UDP/IP/ MAC headers. Job well done. Now it calls
> > netdev->ops->ndo_start_xmit(skb, dev). If your driver is well aware that
> you can Transmit only from network header, why don’t you dma map from
> network header ?
>
> The rest of the network subsystem seems to not add a header to skbs
> submitted to netdev->ops->ndo_start_xmit() at all, which makes sense
> considering
> netdev->header_ops is either NULL or no-op for these devices.
>
> Following this line of reasoning, from API perspective it made more sense to
> me for netpoll to not submit ‘bogus’ skbs that are out-of-line with what the
> rest of the network subsystem does to ndo_start_xmit() to begin with.
> It really depends on the API guarantees we want to have for netdev, but
> personally I'm wary of introducing an allowance for bogus headers.
>
Is below network topology possible ?
Netpoll()- ------> netdev A ----> raw interface
Where netdev A's netdev->header_ops != NULL


> Additionally from a practical perspective, this would require changing almost
> every, if not every, IP interface driver. I took a look at the WireGuard driver to
> see what it would entail, and from my limited experience with the networking
> code it seems like there's some quite annoying interactions with e.g. GSO
> which would make driver-side handling of such packets quite a bit more
> complex.
ACK.

>
> So from my perspective, fixing this in netpoll is both the more API-correct
> change and introduces the least amount of additional complexity.
ACK.