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