public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vasily Averin <vvs@sw.ru>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Patrick McHardy <kaber@trash.net>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	netfilter-devel@lists.netfilter.org, rusty@rustcorp.com.au,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	devel@openvz.org
Subject: Re: [PATCH nf-2.6.22] [netfilter] early_drop imrovement
Date: Sun, 08 Apr 2007 09:02:40 +0400	[thread overview]
Message-ID: <46187770.1070106@sw.ru> (raw)
In-Reply-To: <461789CF.8000106@cosmosbay.com>

Eric Dumazet wrote:
> Vasily Averin a e'crit :
>> When the number of conntracks is reached nf_conntrack_max limit,
>> early_drop() is
>> called and tries to free one of already used conntracks in one of the
>> hash
>> buckets. If it does not find any conntracks that may be freed, it
>> leads to transmission errors.
>> However it is not fair because of current hash bucket may be empty but
>> the
>> neighbour ones can have the number of conntracks that can be freed. On
>> the other
>> hand the number of checked conntracks is not limited and it can cause
>> a long delay.
>> The following patch limits the number of checked conntracks by average
>> number of
>> conntracks in one hash bucket and allows to search conntracks in other
>> hash buckets.
> 
> Hi Vasily
> 
>>
>>              atomic_inc(&ct->ct_general.use);
>>              break;
>>          }
>> +        if (!--(*cnt)) {
>> +            dropped = 1;
>> +            break;
>> +        }
> 
> 
>> +    cnt = (nf_conntrack_max/nf_conntrack_htable_size) + 1;
> 
> I am sorry but this wont help in the case you mentioned in an earlier
> mail :
> 
> If nf_conntrack_max  < nf_conntrack_htable_size, cnt will be set to 1.
> 
> Then in __early_drop() you endup in breaking the
> list_for_each_entry_reverse() loop after the first element was tested !
> Not what you intended I'm afraid, because you wont event scan the whole
> chain as before your patch :(

I would note that in my experiment I got errors when first checked hash bucket
was empty. With this patch I have guarantee that at least one conntrack will be
checked. I'm agree 1 is not too high, but it is better than nothing. I've
checked, my testcase works now.

> I believe you should not test --cnt in __early_drop() but in the caller.
> 
> (That is not counting the number of found cells, but the number of hash
> chains you tried)

I need to count conntracks but not hash buckets. Also it is possible that all
the conntracks will be placed to only one hash bucket, and as you pointed in
your previous letter it may lead to long delays.

However how do you think, is it probably better to set low limit to default
average number of conntracks in hash bucket?

cnt = max(8U, nf_conntrack_max/nf_conntrack_htable_size);

Thank you,
	Vasily Averin


  reply	other threads:[~2007-04-08  5:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-06  8:00 [PATCH 2.6.21-rc6] [netfilter] early_drop imrovement Vasily Averin
2007-04-06  8:24 ` Eric Dumazet
2007-04-06 10:26   ` Vasily Averin
2007-04-06 15:08     ` Patrick McHardy
2007-04-07 11:45       ` [PATCH nf-2.6.22] " Vasily Averin
2007-04-07 12:08         ` Eric Dumazet
2007-04-08  5:02           ` Vasily Averin [this message]
2007-05-09  6:59             ` [NETFILTER] early_drop() imrovement (v3) Vasily Averin
2007-06-25 13:53               ` Patrick McHardy
2007-06-25 14:36                 ` Jan Engelhardt
2007-06-26 13:20                 ` Vasily Averin
2007-06-26 13:27                   ` Patrick McHardy
2007-06-27  8:46                   ` [NETFILTER] early_drop() imrovement (v4) Vasily Averin
2007-06-27  8:52                     ` Patrick McHardy
2007-06-27 12:04                       ` Patrick McHardy
2007-06-27 12:29                         ` Vasily Averin
2007-06-27 12:51                           ` Patrick McHardy
2007-06-27 13:02                             ` Vasily Averin
2007-06-27 13:18                               ` Patrick McHardy
2007-06-27 13:25                                 ` Vasily Averin
2007-06-27 13:28                                   ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46187770.1070106@sw.ru \
    --to=vvs@sw.ru \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=devel@openvz.org \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox