7

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

5
  • Have a look at ethtool, especially ethtool -g
    – ydroneaud
    Jun 22, 2011 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, 2011 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.
    – ydroneaud
    Jun 22, 2011 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, 2011 at 13:29
  • @Damon @ydroneaud maybe interrupt coalescence mentioned here http://datatag.web.cern.ch/datatag/howto/tcp.html is what you are talking about.
    – Utoah
    Jun 23, 2011 at 3:57

3 Answers 3

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.

1
  • 3
    use rx instead of Rx in the above command. i.e. command hsould be ethtool -G <interface> rx <a some big value> Otherwise ethtool throws error - ethtool: bad command line argument(s) Sep 17, 2015 at 11:45
2

The following command might work too:

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

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .