Messages in this thread | | | From | Ratheesh Kannoth <> | Subject | RE: [EXTERNAL] [PATCH] netpoll: support sending over raw IP interfaces | Date | Mon, 18 Mar 2024 14:06:54 +0000 |
| |
> 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.
| |