Messages in this thread | | | From | Ratheesh Kannoth <> | Subject | RE: [EXTERNAL] Re: [PATCH] netpoll: support sending over raw IP interfaces | Date | Thu, 14 Mar 2024 02:46:06 +0000 |
| |
> From: Mark <mark@yotsuba.nl> > Sent: Wednesday, March 13, 2024 7:23 PM > To: Ratheesh Kannoth <rkannoth@marvell.com> > > On 2024-03-13 at 18:16:13, Mark Cilissen (mark@yotsuba.nl) wrote: > >> […] > > Taking an assumption based on dev’s lower layer does not look to be good. > > why not transmit packet from skb_network_header() in your driver (by > > making changes in your driver) > > There’s two assumptions at play here: > - The lower layer is ethernet: this has always been present in netpoll, and is > even > documented in netconsole.rst. This comment just mentions it because we > add a way > to bypass the assumption; it is not an assumption this patch adds to the > code. > - hard_header_len==0 means that there is no exposed link layer: this is a rather > conservative assumption in my opinion, and is also mentioned in the > definition
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 ?
> of LL_RESERVED_SPACE: > > > * Alternative is: > > * dev->hard_header_len ? (dev->hard_header_len + > > * (HH_DATA_MOD - 1)) & ~(HH_DATA_MOD - 1) : 0 > > The same assumption is also made in more places in the core network code, > like af_packet: > > > - If the device has no dev->header_ops->create, there is no LL header > > visible above the device. In this case, its hard_header_len should be 0. > > The device may prepend its own header internally. In this case, its > > needed_headroom should be set to the space needed for it to add its > > internal header. > ACK.
| |