入向路径tc qdisc阶段，skb->transport_header是否始终正确设置？

这个问题问得很到位——确实，skb->transport_header的设置时机并不是在所有入向场景下都一致，它很大程度上取决于网卡驱动的实现细节，咱们一步步拆解：

它的有效性完全取决于驱动的实现逻辑，你测试的virtio_net和veth返回true只是虚拟驱动的特性，不能推广到所有网卡。

1. 先搞懂skb头部指针的常规设置流程 #

在标准的入向路径中：

• 网卡驱动首先接收帧，分配skb并设置skb->mac_header（指向链路层头部的起始位置）；
• 驱动将skb交给内核网络栈，进入__netif_receive_skb_core函数；
• 这里会识别网络层协议（比如IPv4/IPv6），设置skb->network_header；
• 只有当数据包进入传输层处理流程时（比如TCP/UDP的接收函数），才会设置skb->transport_header。

而tc ingress qdisc的处理时机是驱动交付skb之后，网络栈正式处理之前——所以在这个阶段，常规物理驱动的skb还没走到设置transport_header的步骤。

2. 虚拟驱动（virtio_net、veth）的特殊之处 #

像virtio_net、veth这类虚拟驱动，它们的数据包来源是内核内部（比如虚拟机、命名空间之间的转发），而不是物理网卡的原始帧：

• 这些数据包在生成或转发时，已经在内核中完成了头部解析，驱动会直接继承已有的skb头部指针设置；
• 所以当skb到达tc ingress阶段时，transport_header已经被正确初始化，skb_transport_header_was_set()自然返回true。

3. 物理网卡驱动的情况 #

绝大多数物理网卡驱动（比如e1000e、ixgbe）在接收skb时，只会处理链路层：

• 它们只会设置mac_header，network_header和transport_header都保持默认值（等于skb->data）；
• 此时skb_transport_header_was_set()会返回false，如果你在tc动作里直接访问skb->transport_header，会得到错误的地址，甚至触发内核panic。

4. 可靠的处理方式（如果你的tc动作需要访问传输层头部） #

如果你的tc逻辑依赖传输层信息，不要依赖transport_header是否已设置，建议手动解析：

• 先检查skb->network_header是否有效（可以用skb_network_header_was_set()）；
• 根据网络层协议（IPv4用ip_hdr(skb)，IPv6用ipv6_hdr(skb)）获取头部长度，计算传输层头部的偏移；
• 手动设置skb->transport_header（比如skb_set_transport_header(skb, ip_hdrlen)），之后再进行访问。

内容的提问来源于stack exchange，提问作者Mark