Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question

migrated from Jun 25 '11 at 10:30

This question came from our site for professional and enthusiast programmers.

Have a look at ethtool, especially ethtool -g – ydroneaud 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. – ydroneaud 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 is what you are talking about. – Utoah Jun 23 '11 at 3:57

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.

share|improve this answer
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) – Sahil Singh Sep 17 '15 at 11:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.