netdev - [rfc v2 00/10] ipvs network name space (netns) aware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Oct 2010 22:09:34 +0200
From:	Simon Horman <horms@...ge.net.au>
To:	lvs-devel@...r.kernel.org, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org
Cc:	Hans Schillstrom <hans.schillstrom@...csson.com>,
	Julian Anastasov <ja@....bg>,
	Daniel Lezcano <daniel.lezcano@...e.fr>,
	Wensong Zhang <wensong@...ux-vs.org>
Subject: [rfc v2 00/10] ipvs network name space (netns) aware

Hi Hans,

this is a re-base of your patch-set against the current nf-next-2.6 tree,
which includes all the changes currently queued for 2.6.37-rc1 and nothing
else.

I also removed the BUG_ON() statements and incorported various
suggestions that were made in response to your original post.

It is compile tested only (partly because I am in an areoplane).

I have not re-split the patches into logical units.
Having worked with these patches a bit, I really think
that split needs to occur.

For the benefit of others, your original cover email is below,
updated as appropriate.

-----

This patch series adds network name space (netns) support to the LVS.

REVISION

This is version 2

OVERVIEW

The patch doesn't remove or add any functionality except for netns.
For users that don't use network name space (netns) this patch is
completely transparent.

No it's possible to run LVS in a Linux container (see lxc-tools)
i.e.  a light weight virtualization. For example it's possible to run
one or several lvs on a real server in their own network name spaces.
>From the LVS point of view it looks like it runs on it's own machine.

IMPLEMENTATION
Basic requirements for netns awareness
 - Global variables has to be moved to dyn. allocated memory.

Most global variables now resides in a struct ipvs { } in netns/ip_vs.h.
What is moved and what is not ?

Some cache aligned locks are still in global, module init params and some debug_level.

Algorithm files they are untouched.

QUESTIONS
Drop rate in ip_vs_ctl per netns or grand total ?
Should more lock variables be moved (or less) ?

Include files,
A new file added include/net/netns/ip_vs.h containg all netns specific data.
include/net/net_namespce.h, pointer to "struct ipvs"  added.
include/net/ip_vs.h a new struct added, and many prototypes changed.

* ip_vs_core.c
All netns init origins from this file - ip_vs_init()

* ip_vs_conn.c
Lock array for conn table is kept due to performance,
(or am I wrong here ?).
"static struct ip_vs_aligned_lock
__ip_vs_conntbl_lock_array[CT_LOCKARRAY_SIZE] __cacheline_aligned;"

* ip_vs_ctl.c
drop_ rate is still global

TESTING
This patch have been running for a month now with three LVS/machine
one in root name-space and two in other name-space.
Both IPv4 & IPv6 have been tested in all three modes DR/TUN and NAT
Only a limited set of algos have been used (read rr).

Backup have been there all the time and a switch has been performed a couple of times.

Not tested yet:
 Drop level, DOS,  schedulers, performance ....
 Netns exit after usage of LVS (due to a bug in netdev/ipip somewhere tunl0 and

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html