Re: debugging kernel during packet drops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le mardi 23 mars 2010 à 18:21 +0100, Eric Dumazet a écrit :
> Le mardi 23 mars 2010 à 16:14 +0100, Jorrit Kronjee a écrit :
> >   
> > Patrick,
> > 
> > Although these are good suggestions, I really need to be able to limit
> > per destination. The receiving network is a /15 which means I have to
> > use something like a hashtable to keep track of destination IP
> > addresses. Neither rateest or limit can do that. OTOH, that's also the
> > only thing I need. This would make a low-cost ISP-grade DDoS filter,
> > which is why I'm interested in it.
> > 
> > The bug you're referring to is this one, I think: 
> > http://bugzilla.netfilter.org/show_bug.cgi?id=523 but I'm not entirely
> > sure if that is related to my problems.
> > 
> > Is there any way I can figure out why ifconfig is reporting dropped
> > packets?
> > 
> > Thanks for all the help so far!
> > 
> 
> Could you post more information about your machine ?
> 
> cat /proc/interrupts
> 
> If running a recent kernel, a "perf top" would be useful
> 
> Maybe RPS will help your setup  (included in net-next-2.?6 tree)
> 

If your NIC are multiqueue enabled, we might upgrade hashlimit to a more
scalable module, using several locks instead of one per table, or maybe
RCU.

One known problem with hashlimit is its garbage collector, run from
timer softirq, holding this central lock for a possible long period.



--
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

[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux