Re: netfilter queue throughput slowdown

[Eric Dumazet <eric.dumazet@gmail.com>]

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@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 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html