dev_queue_xmit和rtl8139_start_xmit函数数据包数目不一致

瀚海书香

回复 10# markdong_007
你的内核是不是大于2.6.18？
如果是的话，貌似知道原因了。

   

markdong_007

回复 11# 瀚海书香

内核版本是2.6.38   请问是什么原因呀？


   

瀚海书香

回复 12# markdong_007
我猜测是GSO的问题。你把网卡的gso和tso关掉，再测试一下看看结果。

   

markdong_007

回复 13# 瀚海书香

请问怎么关掉呀？  指点我一下  谢谢


   

瀚海书香

回复 14# markdong_007
ethtool -K eth0 gso off
ethtool -K eth0 tso off

markdong_007

回复 15# 瀚海书香

谢谢 我试试再看看


   

markdong_007

回复 15# 瀚海书香


hi  前辈  你好  我在统计dev_queue_xmit和rtl8139_start_xmit函数中的数据包数目，发现他们的值仍然不一致，上次你跟我说过是gso的问题后，我把gso关掉了，现在结果还是不一样，大约差一倍多的数目，前辈，请问你晓得是什么原因啊  谢谢


   

honkiko

回复 17# markdong_007

你使用了pkt_gen发包吗？ pkt_gen直接调 dev->netdev_ops->ndo_start_xmit()

还有一个可能，一个skb调用一次dev_queue_xmit, 会被加入到tx queue。然后在__qdisc_run()里面会循环调用sch_direct_xmit()。 关键在这个sch_direct_xmit函数里面：
如果dev_hard_start_xmit()的返回值不是NETDEV_TX_OK (而是NETDEV_TX_LOCKED或NETDEV_TX_BUSY), 会调用dev_requeue_skb()把这个skb重新加入tx queue，然后下次还会走到dev_hard_start_xmit()。
所以，如果你的ndo_start_xmit经常返回NETDEV_TX_LOCKED或NETDEV_TX_BUSY的话，就会造成两个counter的不一致。
你可以在rtl8139_start_xmit函数里专门加一个发送失败(NETDEV_TX_LOCKED或NETDEV_TX_BUSY)的counter, 然后看看这个counter的值，是不是就是dev_queue_xmit跟rtl8139_start_xmit调用次数之间的差别。

markdong_007

回复 18# honkiko
嗯 我没有用pktgen   之前我也看到了pktegn是不能统计dev_queue_xmit函数的，我觉得你说的第二个原因非常有道理，谢谢你

   

markdong_007

回复 19# markdong_007

对了 前辈  你有什么比较好的发包工具吗？ 我是用的socket来发包统计的  感觉比较慢