Generic sk_buff contract documentation ?
Alexandre Ferrieux
alexandre.ferrieux at gmail.com
Mon Jan 13 17:58:50 EST 2025
Hi,
Recently digging into a driver-specific issue with sk_buff->protocol, I
discovered (with surprise) that the computation of this field (which is *always*
necessary for protocol handlers to kick in) was somehow "delegated" to
individual network interface drivers. This can be seen by looking for callers of
eth_type_trans(), e.g:
- tg3: called from tg3_poll_work
- ixgbe: called from ixgbe_clean_rx_irq
- veth: called from veth_xmit (though indirectly via __dev_forward_skb)
This is a surprise as one would naively expect this ubiquitous behavior to be
triggered from generic code, depending only on the L2 header structure (but not
on the specific NIC hardware at hand). Another surprise was *not* to find any
mention of this "contract" in Documentation/*.
So, is it an unspoken tradition for NIC driver developers, to
"just know" that prior to emitting an skb from the rx path, they must fill
skb->protocol (along with who knows how many other metadata items) ?
Or, is there *somewhere* some reference documentation listing (exhaustively) the
required metadata computations that fall within a NIC driver's responsibility ?
Thanks in advance,
-Alex
More information about the Kernelnewbies
mailing list