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

[Ratheesh Kannoth <rkannoth@marvell.com>]

> From: Mark <mark@yotsuba.nl>
> Sent: Monday, March 18, 2024 5:13 PM
> To: Ratheesh Kannoth <rkannoth@marvell.com>
> Cc: netdev@vger.kernel.org; Hans de Goede <hdegoede@redhat.com>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Breno
> Leitao <leitao@debian.org>; Ingo Molnar <mingo@redhat.com>; David S.
> Miller <davem@davemloft.net>; Paolo Abeni <pabeni@redhat.com>; linux-
> kernel@vger.kernel.org
> 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@marvell.com> het volgende geschreven:
> >
> >> From: Mark <mark@yotsuba.nl>
> >> […]
> >
> > 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.