Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Simon Horman <horms@verge.net.au>
Cc: Franchoze Eric <franchoze@yandex.ru>,
	wensong@linux-vs.org, lvs-devel@vger.kernel.org,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: Fwd: LVS on local node
Date: Thu, 22 Jul 2010 14:59:43 +0200	[thread overview]
Message-ID: <1279803583.2467.43.camel@edumazet-laptop> (raw)
In-Reply-To: <20100722122422.GD16234@verge.net.au>

Le jeudi 22 juillet 2010 à 21:24 +0900, Simon Horman a écrit :
> On Thu, Jul 22, 2010 at 08:56:51AM +0200, Eric Dumazet wrote:
> 
> [snip]
> 
> > lvs seems not very SMP friendly and a bit complex.
> 
> I'd be interested to hear some thoughts on
> how the SMP aspect of that statement could
> be improved.

Hi Simon

I am not familiar with LVS code, so I am probably wrong, but it seems it
could be changed a bit.

Some rwlocks might become spinlocks (faster than rwlocks)

__ip_vs_securetcp_lock for example is always used with
write_lock()/write_unlock().
This can be a regular spinlock without even knowing the code.

Some lookups could use RCU to avoid cache line misses, and to be able to
use spinlocks for the write side.

It would be good to have a bench setup with the case of 16 legacy
daemons, and check how many new connections per second can be
established, in an LVS setup and an iptables based one.

With 2.6.35 and RPS, a REDIRECT based solution can chose the target port
without taking any lock (not counting conntrack internal costs of
course), each cpu accessing local memory only.

# No need is eth0 is a multiqueue NIC
echo ffff >/sys/class/net/eth0/queues/rx-0/rps_cpus

for c in `seq 0 15`
do
  iptables -t nat -A PREROUTING -p tcp --dport 80 -m cpu --cpu $c -j
REDIRECT --to-port $((1000 + $c))
done




  reply	other threads:[~2010-07-22 12:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-22  3:51 Fwd: LVS on local node Franchoze Eric
2010-07-22  6:56 ` Eric Dumazet
2010-07-22  9:10   ` Changli Gao
2010-07-22  9:46     ` Eric Dumazet
2010-07-22  9:52       ` Changli Gao
2010-07-22  9:59         ` Eric Dumazet
2010-07-22 10:06           ` Changli Gao
2010-07-23 10:54       ` Patrick McHardy
2010-07-22 12:24   ` Simon Horman
2010-07-22 12:59     ` Eric Dumazet [this message]
2010-07-22 13:20       ` Simon Horman
2010-07-22 18:45   ` Franchoze Eric
2010-07-22 13:25 ` Simon Horman
2010-07-22 16:59   ` Franchoze Eric
2010-09-20  5:56     ` Simon Horman

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=1279803583.2467.43.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=franchoze@yandex.ru \
    --cc=horms@verge.net.au \
    --cc=lvs-devel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox