82599EB万兆网卡环境下关闭tso后， sk_buff不能提取实际数据
环境： readhat 64位 ，内核2.6.39 , 网卡设置为混杂模式万兆网卡信息：
Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFP+ Network Connection (rev 01)
# ethtool eth4
Settings for eth4:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseT/Full
10000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes:10000baseT/Full
Advertised auto-negotiation: Yes
Speed: 10000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
在关闭tso、gso、gro等特性后, 在驱动dev.c 中__netif_receive_skb 提取的数据包仍然大于MTU（1500）值，并且数据不是实际的数据帧。
后又将tx、rx 选项也关闭，如下。提取的数据包才不大于MTU，但是提取的数据依然不是实际的数据帧。
譬如：
第一个数据包seq为1 ack为1 , len为25，去除ip和tcp头后，包为GET /poratl/test HTTP/1.1 。（提取的正确）
第二个数据包seq为26，ack为1，len为10，去除ip和tcp头后，包实际为User-Agent: Axis2，但是提取出来的却是类似cfT /poratl/test HTTP/1.1的东西。（提取的不正确）
1、请问是否网卡还有其他的优化选项需要关闭？？才能从sk_buff中提取出实际的数据帧。
2、我在千兆网卡的环境中只要关闭tso，就能提取出正确的数据，但是在该万兆网卡中却不行。不知道什么原因。
# ethtool -k eth4
Offload parameters for eth4:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off
真心求教啊，烦请高手了！
tso是跟发送相关的，为啥会影响rx?
能简单的展示一下在__netif_receive_skb里面查看包内容的代码么？
第一个包长度是25也不对吧？“GET /poratl/test HTTP/1.1”是25byte，还差\n呢？ 回复 2# nswcfd
您好，
1、支持tso等特性的网卡会做一些组包操作，使得我__netif_receive_skb 拿到的包大于MTU 1500 值。
我关闭了tso、gso、gro、tx、rx 选项全部关闭后，就不会组包超过1500 ，如果rx和tx不关闭的话，还是会超过1500.
2、__netif_receive_skb 代码
struct iphdr*iph ;
skb_tail = skb_tail_pointer(skb);
mac_header = skb_mac_header(skb);
network_header = skb_network_header(skb);
if (ntohs(((struct ethhdr*)mac_header)->h_proto) == ETH_P_8021Q){
if (ntohs(((struct vlan_ethhdr*)mac_header)->h_vlan_encapsulated_proto) != ETH_P_IP ){
//不是ip数据包
goto pass ;
}
//IP包头
iph=(struct iphdr *)(network_header+4);
} else {
if (ntohs(((struct ethhdr*)mac_header)->h_proto) != ETH_P_IP){
//不是ip数据包
goto pass ;
}
//IP包头
iph=(struct iphdr *)network_header;
}
iph ----> 拿到的iph 减去 ip头和tcp 头，剩下就是包的内容。
如果连续多个包，第一个包里面的内容是正确的，后面的就会存在包错位、或者包不全的现象。
例如下面：
*****************time-item.count-head_node********************
POST /XMLReceiver HTTP/1.1 -------------> 第一个包是正常
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 1442
Host: 132.194.38.234:12026
Connection: Keep-Alive
node,head_node==>seq,ack,next_seq,offset,
np==>seq,ack,next_seq,datasize
xmST /XMLReceiver HTTP/1.1 ---------------------->第二个包的前两个字符为xm，后面的内容为第一个包的内容。
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 1442
Host: 132.194.38.234:12026
Connection: Keep-Alive 回复 2# nswcfd
44:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFP+ Network Connection (rev 01)
驱动ixgbe.ko
目前的现象我还是怀疑网卡做了优化操作，除了tso等特性外，还有哪些特性会做组包的优化呢？
请问第二个包的iph->saddr,iph->daddr,tcph->source,tcph->dest等信息是否正确？
不妨增加一些打印信息，把上面提到的几个字段，连同skb->len，skb->data_len，iph->tot_len等长度相关的信息一起输出一下。
作为对比，建议临时bypass以上代码，用标准工具tcpdump检查输入的报文内容是否符合期望。
如果tcpdump没啥问题的话，那问题就不在驱动上。
另外，访问skb_buffer数据区域的方式是什么样的？顺着skb->data一直往后线性增加偏移？
建议检查一下l3/l4/l7指针有没有超过skb_tail？
PS，关于第一点，如何判断__netif_receive_skb收到的包大于MTU 1500的？看skb->len?
调整gso/tso等选项的过程中，device的MTU是多少，有没有进行调整？
页:
[1]