From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: netfilter queue throughput slowdown Date: Thu, 30 Jun 2011 08:47:06 +0200 Message-ID: <1309416426.2532.119.camel@edumazet-laptop> References: <1309340843.2532.112.camel@edumazet-laptop> <1309342096.2532.116.camel@edumazet-laptop> <4E0C15A3.9050609@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Anders Nilsson Plymoth , netfilter-devel To: Kuzin Andrey Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:43493 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752512Ab1F3GrM (ORCPT ); Thu, 30 Jun 2011 02:47:12 -0400 Received: by wyg8 with SMTP id 8so1324553wyg.19 for ; Wed, 29 Jun 2011 23:47:11 -0700 (PDT) In-Reply-To: <4E0C15A3.9050609@yandex.ru> Sender: netfilter-devel-owner@vger.kernel.org List-ID: Le jeudi 30 juin 2011 =C3=A0 10:20 +0400, Kuzin Andrey a =C3=A9crit : > On 29.06.2011 14:08, Eric Dumazet wrote: > > Le mercredi 29 juin 2011 =C3=A0 11:55 +0200, Anders Nilsson Plymoth= a =C3=A9crit : > >> Hi Eric, > >> > >> Thanks for your reply. > >> Yes, I am sure I set the verdict, as right now I do it on all pack= ets > >> 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 li= st > > and each dequeue is slower since it has to go past these packets... > > > > 2.6.37 also contains commit 29b4433d991c88d86ca48a4c1cc33c671475be4= b > > (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@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > Hello. > I'am using NFQUEUE several years on our main network router, and prob= lem=20 > 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= =20 > use simple program with ACCEPT verdict on all packets, and after some > time queue has packets without any verdict, result is large (and=20 > increased) delays on every packet and waste CPU time. >=20 > I'am write patch for this, but it doesn't apply by any netfilter=20 > developers. Today i'am not using any kernel without this NFQUEUE patc= h. >=20 > diff --git a/net/netfilter/nfnetlink_queue.c=20 > 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,=20 > struct nf_queue_entry *entry) > queue->queue_total++; > } >=20 > +#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 =3D NULL, *i; > + struct nf_queue_entry *entry =3D NULL, *next, *i; > + ktime_t kt =3D ktime_get_real(); >=20 > spin_lock_bh(&queue->lock); >=20 > - list_for_each_entry(i, &queue->queue_list, list) { > + list_for_each_entry_safe(i, next, &queue->queue_list, list) { > if (i->id =3D=3D id) { > entry =3D i; > break; > + } else { > + struct timeval tv =3D=20 > ktime_to_timeval(ktime_sub(kt, i->skb->tstamp)); > + if (tv.tv_sec > NFQNL_TIMEOUT_ENTRY_DROP) { > + printk(KERN_ERR "nf_queue: drop=20 > timeouted packet " > + "(queue_num=3D%d seq_id=3D%d)= \n",=20 > queue->queue_num, i->id); > + list_del(&i->list); > + queue->queue_total--; > + nf_reinject(i, NF_DROP); > + } > } > } >=20 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-dev= el" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html