From: Hans Schillstrom <hans@schillstrom.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: Simon Horman <horms@verge.net.au>,
Pablo Neira Ayuso <pablo@netfilter.org>,
lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org,
Wensong Zhang <wensong@linux-vs.org>
Subject: Re: [PATCH ipvs-next] ipvs: Remove rcu_read_unlock();rcu_read_lock();
Date: Thu, 25 Apr 2013 11:05:26 +0200 [thread overview]
Message-ID: <1366880726.2628.177.camel@hawk.mlab.se> (raw)
In-Reply-To: <alpine.LFD.2.00.1304251038541.1752@ja.ssi.bg>
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
Hello
On Thu, 2013-04-25 at 11:15 +0300, Julian Anastasov wrote:
> Hello,
>
> On Thu, 25 Apr 2013, Simon Horman wrote:
>
> > It is unclear to me that there is any utility in the following:
> >
> > rcu_read_unlock();
> > rcu_read_lock();
>
> I thought it is a good idea for fixed hash table
> of IP_VS_TAB_BITS=20. May be if guarded by
>
> if (!((++idx) & 4095))
>
> to reduce its rate to 256 (with idx++ removed from the for loop) ?
>
> Netfilter has no such logic for nf_conntrack because
> it has limit of 16384 rows. Not sure how fatal is to try 1048576
> empty rows under RCU lock for such rare operations as
> connection listing. OTOH, ip_vs_conn_array() needs to
> seek at some initial position, so it can skip many
> entries if reading table with many conns, for example,
> 1048576 rows * 16 conns per row, we will need to
> touch 16777216 conns under lock. Not sure what is the
> best practice for such cases.
My opinion is to keep it, people tends to do such "rare" things.
It's not unusual with 256k - 1M rows...
Regards
Hans
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6177 bytes --]
next prev parent reply other threads:[~2013-04-25 9:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-25 1:12 [PATCH ipvs-next] ipvs: Remove rcu_read_unlock();rcu_read_lock(); Simon Horman
2013-04-25 8:15 ` Julian Anastasov
2013-04-25 9:05 ` Hans Schillstrom [this message]
2013-04-25 13:36 ` Simon Horman
2013-04-25 14:04 ` Eric Dumazet
2013-04-25 19:46 ` Julian Anastasov
2013-04-26 0:28 ` Simon Horman
2013-04-26 0:59 ` Pablo Neira Ayuso
2013-04-26 6:02 ` Julian Anastasov
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=1366880726.2628.177.camel@hawk.mlab.se \
--to=hans@schillstrom.com \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=lvs-devel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=wensong@linux-vs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.