6

I have a server running Linux (kernel 2.6.18) which is dropping incoming network packets drastically. I thought it is suffering from this because the length of the receive queue of that interface is too small (1000 by default). I wanted to enlarge this queue by modifying the value of /proc/sys/net/core/netdev_max_backlog (to 3000). But it did not seem to work. I googled it and found someone say this value only applies to non-NAPI devices which I did not think my device is as NAPI had been introduced since kernel 2.4.20. I did not know whether this is true and turned to the kernel doc installed on the that server, but that doc had not been updated since kernel 2.2.

So I wonder whether this is true, if it is, how can I change that queue length for a NAPI device?

Thanks. Feng

Utoah
  • 281
  • 1
  • 2
  • 6
  • Have a look at ethtool, especially ethtool -g –  Jun 22 '11 at 10:43
  • Out of my belly, I would rather try increasing `/proc/sys/net/core/rmem_default`. Normally the device backlog should have no meaning at all nowadays since normally the kernel will get an interrupt for every packet, copy the data to its buffers, and continue. Of course, if a lot of data arrives and the buffer becomes full, there's not much to do but drop the packet. The receive queue length only really has a meaning when polling, afaik. – dm.skt Jun 22 '11 at 13:02
  • @Damon a interrupt for every packet would be overkill for a stream of packet ! Let's the network adapter throttle the interrupt which allows the kernel to process more packet during that time. –  Jun 22 '11 at 13:21
  • @ydroneaud: Hmm yes, you're right, a good adapter should hopefully do some kind of rate-limiting under extreme load. Though I've repeatedly heard of IRQ storms totally locking out Linux servers on some hardware (never experienced one myself). Maybe there's room for implementation details there too :) – dm.skt Jun 22 '11 at 13:29
  • @Damon @ydroneaud maybe `interrupt coalescence` mentioned here [http://datatag.web.cern.ch/datatag/howto/tcp.html](http://datatag.web.cern.ch/datatag/howto/tcp.html) is what you are talking about. –  Jun 23 '11 at 03:57

3 Answers3

11

I finally found that the interface was dropping packets because the driver was configured with a too small Rx descriptor size, which, while working with interrupt coalescence, decides how many packets the driver can hold before it sends the kernel an interrupt. If this value (shown with ethtool -g <interface>) is too small, packets will be dropped before an interrupt can be raised. After I enlarged it with ethtool -G <interface> Rx <a some big value>, no droppings have arisen since.

Thank you everyone.

Utoah
  • 281
  • 1
  • 2
  • 6
2

The following command might work too:

/sbin/sysctl -w net.core.netdev_max_backlog = 10000

user9224
  • 21
  • 1
1

In the output of ethtool -g you will get the de "Pre-set maximums" and the "Current hardware settings" of your NIC. It should always be recommended to set your settings to the max allowed value to avoid packet drops but more specifically: rx errors or overruns(which can happen in case of burst for example).

Even in some cases, there are driver updates that can increase the "Pre-set maximums" values of the NIC, all depending of the model of course.

Colinz
  • 11
  • 2