Le mardi 23 mars 2010 à 10:04 -0700, James King a écrit : > On Mon, Mar 22, 2010 at 3:41 AM, Jorrit Kronjee <j.kronjee@xxxxxxxxxxx> wrote: > > At around 300 kpps, the amount of packet drops is 40 kpps. For me, this > > amount is too significant to ignore. I see the load average go from a > > comfortable 0.00 to 1.78, mainly caused by ksoftirqd processes. At 200 > > kpps, the average amount of packet drops is 23 kpps. At 100 kpps, it's > > still 2 kpps. > > > > When I disable the hashlimit module the packet drops disappear again. > > Now I know that hashlimit is made for more than one thing, namely > > limiting packets based on source/destination host and source/destination > > port, so it's not as efficient as it could be for my purposes. I could > > rewrite it, but before I do that, I would like to know if the module > > itself is really what's causing it, or if there's some underlying cause > > that I'm not seeing. So my question in short: how can I discover why > > it's dropping packets? > > I'm not sure whether it's even related to the problem you're having, > but I had a similar problem on a bnx2 interface with high packet rates > when using l7-filter. ifconfig reported huge numbers of dropped > packets, corresponding to rx_fw_discards from "ethtool -S ethX" > output. I resolved this by bumping up the driver RX ring size (which > was defaulting to 100 out of a maximum possible size of 1020). > - If increasing latencies is OK, then yes, increasing queue lengthes is an answer. Sometime, its better to drop packets after a given threshold of workload. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
