Le jeudi 30 juin 2011 à 10:20 +0400, Kuzin Andrey a écrit : > On 29.06.2011 14:08, Eric Dumazet wrote: > > Le mercredi 29 juin 2011 à 11:55 +0200, Anders Nilsson Plymoth a écrit : > >> Hi Eric, > >> > >> Thanks for your reply. > >> Yes, I am sure I set the verdict, as right now I do it on all packets > >> by default. > >> I will try upgrading and see if it works. Do you know if commit > >> c463ac972315a0 solves the problem you mentioned? > > No, it doesnt solve the problem, only make things faster. > > > > But if some packets are never dequeued (because something is wrong with > > your program, failing to give verdict), they stay forever in the list > > and each dequeue is slower since it has to go past these packets... > > > > 2.6.37 also contains commit 29b4433d991c88d86ca48a4c1cc33c671475be4b > > (net: percpu net_device refcount) which helps a lot netfilter > > queue/dequeue if your machine is SMP. > > > > > > > > -- > > 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 > > > > > Hello. > I'am using NFQUEUE several years on our main network router, and problem > with packets stuck in the queue is still not resolved. > But in the past when i use libipq, it not have this problem. I try to > use simple program with ACCEPT verdict on all packets, and after some > time queue has packets without any verdict, result is large (and > increased) delays on every packet and waste CPU time. > > I'am write patch for this, but it doesn't apply by any netfilter > developers. Today i'am not using any kernel without this NFQUEUE patch. > > diff --git a/net/netfilter/nfnetlink_queue.c > b/net/netfilter/nfnetlink_queue.c > index 8c86011..74fc322 100644 > --- a/net/netfilter/nfnetlink_queue.c > +++ b/net/netfilter/nfnetlink_queue.c > @@ -169,17 +169,29 @@ __enqueue_entry(struct nfqnl_instance *queue, > struct nf_queue_entry *entry) > queue->queue_total++; > } > > +#define NFQNL_TIMEOUT_ENTRY_DROP 20 > + > static struct nf_queue_entry * > find_dequeue_entry(struct nfqnl_instance *queue, unsigned int id) > { > - struct nf_queue_entry *entry = NULL, *i; > + struct nf_queue_entry *entry = NULL, *next, *i; > + ktime_t kt = ktime_get_real(); > > spin_lock_bh(&queue->lock); > > - list_for_each_entry(i, &queue->queue_list, list) { > + list_for_each_entry_safe(i, next, &queue->queue_list, list) { > if (i->id == id) { > entry = i; > break; > + } else { > + struct timeval tv = > ktime_to_timeval(ktime_sub(kt, i->skb->tstamp)); > + if (tv.tv_sec > NFQNL_TIMEOUT_ENTRY_DROP) { > + printk(KERN_ERR "nf_queue: drop > timeouted packet " > + "(queue_num=%d seq_id=%d)\n", > queue->queue_num, i->id); > + list_del(&i->list); > + queue->queue_total--; > + nf_reinject(i, NF_DROP); > + } > } > } > You do realize we have to find out what happened to these packets, why no verdict was given at all ? Also, where skb->tstamp is set exactly ? This depends on netstamp_needed ? -- 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
