On Mon, Sep 14, 2020 at 9:42 AM Xie He <[email protected]> wrote: > > This comment is outdated and no longer reflects the actual implementation > of af_packet.c. > > Reasons for the new comment: > > 1. > > In af_packet.c, the function packet_snd first reserves a headroom of > length (dev->hard_header_len + dev->needed_headroom). > Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header, > which calls dev->header_ops->create, to create the link layer header. > If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of > length (dev->hard_header_len), and checks if the user has provided a > header sized between (dev->min_header_len) and (dev->hard_header_len) > (in dev_validate_header). > This shows the developers of af_packet.c expect hard_header_len to > be consistent with header_ops. > > 2. > > In af_packet.c, the function packet_sendmsg_spkt has a FIXME comment. > That comment states that prepending an LL header internally in a driver > is considered a bug. I believe this bug can be fixed by setting > hard_header_len to 0, making the internal header completely invisible > to af_packet.c (and requesting the headroom in needed_headroom instead). > > 3. > > There is a commit for a WiFi driver: > commit 9454f7a895b8 ("mwifiex: set needed_headroom, not hard_header_len") > According to the discussion about it at: > https://patchwork.kernel.org/patch/11407493/ > The author tried to set the WiFi driver's hard_header_len to the Ethernet > header length, and request additional header space internally needed by > setting needed_headroom. > This means this usage is already adopted by driver developers. > > Cc: Willem de Bruijn <[email protected]> > Cc: Eric Dumazet <[email protected]> > Cc: Brian Norris <[email protected]> > Cc: Cong Wang <[email protected]> > Signed-off-by: Xie He <[email protected]>
Acked-by: Willem de Bruijn <[email protected]>
