On Mon, Sep 14, 2020 at 9:42 AM Xie He <xie.he.0...@gmail.com> 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 <willemdebruijn.ker...@gmail.com> > Cc: Eric Dumazet <eric.duma...@gmail.com> > Cc: Brian Norris <briannor...@chromium.org> > Cc: Cong Wang <xiyou.wangc...@gmail.com> > Signed-off-by: Xie He <xie.he.0...@gmail.com>
Acked-by: Willem de Bruijn <will...@google.com>