> Note that "dropping" was meant to be more generic than just dropping a
> packet. We can decide to drop packets proactively by just deciding to
> disable the interface completely for a while, to make sure it doesn't
> flood us with interrupts. That's obviously fairly extreme, but it might be
> the simplest answer (the driver could even decide on its own to disable
> itself if it sees overlong backlog queues, as long as we'd have some way
> of enabling it again when the queue empties - by a timer or something).
I'm reluctant to put this functionality in every driver unless it's
required. A better case can be made if the underlying hardware supports
flow control. (Note: it's often not easy to trigger flow control in
software. The best way is to let the Rx buffers run dry, which means 16 or
32 more Rx packets.)
I think you've made a good case that the Rx packet overload might be better
solved by limiting the bottom half work. I was guessing that it was the
interrupt handler work that was causing the problem. I should have
questioned that assumption -- my own measurements indicate the driver Rx
code doesn't consume a lot of CPU time.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/