网卡驱动的问题
sdf
又来请教大家了，呵呵！不好意思！上网搜了好多关于网络数据接收的资料，好像大家都是在驱动和网络协议方面进行改进优化，从而能使网络数据包能及时处理，减少丢包。那么，我就想知道，如果不考虑网络数据包的处理，只考虑网络数据包从网卡缓存DMA到主内存的这一过程（假设内存足够大、接收描述符足够多），是不是在这一过程是不会产生丢包的？也就是说，在硬件上不存在丢包的问题，只是因为数据包要及时的处理，不能无限期的接收（要不然收包也就没意义了，对吧）？？如果说只是软件方面的问题，那么是驱动的问题大点，还是内核网络协议的问题大点呢？
感谢大家的关注！
雷鸣
_______________________________________________
Linux 内核开发中文邮件列表
Linux-...@zh-kernel.org
http://zh-kernel.org/mailman/listinfo/linux-kernel
Linux 内核开发中文社区： http://zh-kernel.org
Bruce Majia
> 大家好：
> 又来请教大家了，呵呵！不好意思！上网搜了好多关于网络数据接收的资料，好像大家都是在驱动和网络协议方面进行改进优化，从而能使网络数据包能及时处理，减少丢包。那么，我就想知道，如果不考虑网络数据包的处理，只考虑网络数据包从网卡缓存DMA到主内存的这一过程（假设内存足够大、接收描述符足够多），是不是在这一过程是不会产生丢包的？也就是说，在硬件上不存在丢包的问题，只是因为数据包要及时的处理，不能无限期的接收（要不然收包也就没意义了，对吧）？？如果说只是软件方面的问题，那么是驱动的问题大点，还是内核网络协议的问题大点呢？
> 感谢大家的关注！
> 雷鸣
似乎是方案的问题。OT了。这样的问题，是咨询公司的饭碗了。呵呵。
-M.J
Liuweni
接收到的socket_buffer会从驱动往上，一层一层的解包。这个过程应该不会有数据丢失现象。
举个例子，在TCP协议里有个重传的机制，也就是在协议层没有收到相应的包，所以再要求重传，这个的丢包检测是在协议层了。
2009-12-17
Liuweni
发件人： sdf
发送时间： 2009-12-16 22:03:45
收件人： linux-kernel
抄送：
主题： 网卡驱动的问题
大家好：
又来请教大家了，呵呵！不好意思！上网搜了好多关于网络数据接收的资料，好像大家都是在驱动和网络协议方面进行改进优化，从而能使网络数据包能及时处理，减少丢包。那么，我就想知道，如果不考虑网络数据包的处理，只考虑网络数据包从网卡缓存DMA到主内存的这一过程（假设内存足够大、接收描述符足够多），是不是在这一过程是不会产生丢包的？也就是说，在硬件上不存在丢包的问题，只是因为数据包要及时的处理，不能无限期的接收（要不然收包也就没意义了，对吧）？？如果说只是软件方面的问题，那么是驱动的问题大点，还是内核网络协议的问题大点呢？
感谢大家的关注！
雷鸣
胜文沈
2009/12/17 Liuweni <qings...@gmail.com>
--
此致
敬礼
沈胜文
Liuweni
不过，如果处理的时间足够长，数据接收的足够多，那么丢包是肯定的。(这“两个足够”应属于废话…………*_^)
------------------
Liuweni
2009-12-17
-------------------------------------------------------------
发件人：胜文沈
发送日期：2009-12-17 18:11:10
收件人：Liuweni
抄送：sdf; linux-kernel
主题：Re: 网卡驱动的问题
我记得RTL的网卡芯片上是有一个接收与发送的FIFO的，驱动最开始是从这个FIFO里接收数据或是将数据发送至该FIFO，若驱动处理过慢，会不会造成丢包现像？
2009/12/17 Liuweni <qings...@gmail.com>
此致
敬礼
沈胜文
goldenwang1979
我记得RTL的网卡芯片上是有一个接收与发送的FIFO的，驱动最开始是从这个FIFO里接收数据或是将数据发送至该FIFO，若驱动处理过慢，会不会造成丢包现像？
－－－>这种情况设置正确的话，会发生一个异常中断，协议层根据这个信息可以要求重传
Best regards.
王金堂
2009-12-21
-------------------------------------------------------------
发件人：胜文沈
发送日期：2009-12-17 18:11:24
抄送：sdf; linux-kernel
胜文沈
这种异常中断，只能由驱动进行响应。协议层根据驱动层的数据进行处理，是否要求重传应该与协议有关，如TCP或是UDP。我认为，即便设置正确，产生异常中断，也需要上层（应用层）根据数据包和协议进行处理。
2009/12/21 goldenwang1979 <goldenw...@yahoo.com.cn>
yao zhao
> On Wed, Dec 16, 2009 at 10:03:21PM +0800, sdf wrote:
> > 大家好：
> >
> 又来请教大家了，呵呵！不好意思！上网搜了好多关于网络数据接收的资料，好像大家都是在驱动和网络协议方面进行改进优化，从而能使网络数据包能及时处理，减少丢包。那么，我就想知道，如果不考虑网络数据包的处理，只考虑网络数据包从网卡缓存DMA到主内存的这一过程（假设内存足够大、接收描述符足够多），是不是在这一过程是不会产生丢包的？也就是说，在硬件上不存在丢包的问题，只是因为数据包要及时的处理，不能无限期的接收（要不然收包也就没意义了，对吧）？？如果说只是软件方面的问题，那么是驱动的问题大点，还是内核网络协议的问题大点呢？
>
I think so it won't lose packet if just dma to main memory from adapter's
fifo, if memory is fast enough. Most adapter should support loop mode, you
can try it or modify your driver to remove the delivery to upper layer code
and just put the buffer back to BD list.
> 感谢大家的关注！
> >
> 雷鸣
>
> 似乎是方案的问题。OT了。这样的问题，是咨询公司的饭碗了。呵呵。
>
> -M.J
> _______________________________________________
> Linux 内核开发中文邮件列表
> Linux-...@zh-kernel.org
> http://zh-kernel.org/mailman/listinfo/linux-kernel
> Linux 内核开发中文社区： http://zh-kernel.org
>
Just like what MJ said: 方案的问题. If cpu is too slow to receive or cpu is too
fast to send or too much cpu load then will lose packets so ...
Bruce Majia
>
>
> 2009/12/16 Bruce Majia <bruce...@gmail.com>
>
> On Wed, Dec 16, 2009 at 10:03:21PM +0800, sdf wrote:
> > 大家好：
> > 又来请教大家了，呵呵！不好意思！上网搜了好多关于网络数据接收的资料
> ，好像大家都是在驱动和网络协议方面进行改进优化，从而能使网络数据包能及时处
> 理，减少丢包。那么，我就想知道，如果不考虑网络数据包的处理，只考虑网络数据
> 包从网卡缓存DMA到主内存的这一过程（假设内存足够大、接收描述符足够多），是不
> 是在这一过程是不会产生丢包的？也就是说，在硬件上不存在丢包的问题，只是因为
> 数据包要及时的处理，不能无限期的接收（要不然收包也就没意义了，对吧）？？如
> 果说只是软件方面的问题，那么是驱动的问题大点，还是内核网络协议的问题大点呢
> ？
>
> I think so it won't lose packet if just dma to main memory from adapter's fifo,
> if memory is fast enough. Most adapter should support loop mode, you can try
> it or modify your driver to remove the delivery to upper layer code and just
> put the buffer back to BD list.
还在讨论呢。网络处理这块国内不少公司在做吧。这个不仅仅是驱动的问题在里面
。本ML上应该有不少干这行的兄弟姐妹。只是大家都没怎么出来说话罢了。建议楼
主仔细想想什么是linerate，为什么会有这个东东，以及所谓的做网络处理器的兄
弟都在那些方面下功夫，以及高速网络设备的设计方案。相信比死抠驱动啥的更能
有所补益。
祝好。
Wenxy
NIC驱动是比较成熟了，例如Intel的千兆网卡，以Intel的实力，绝对可靠。
国内做TCP/IP协议栈的优化的公司也有一些，最新兴的领域是 fast TCP.
Best regards.
Wenxy.
2009-12-22,09:40:00
Email: wen_k...@163.com
Blog: http://blog.csdn.net/wenxy1