Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
From: Daniel Lezcano [EMAIL PROTECTED]
Denis Lunev spotted that if we take a reference to the network namespace
with the timewait sockets, we will need to wait for their expiration to
have the network namespace freed
Denis Lunev spotted that using a reference to the network namespace
with the timewait sockets will be a waste of time because they
are pointless while we will remove the network stack at network
namespace exit.
The following patches do the following:
- fix missing network namespace
From: Daniel Lezcano [EMAIL PROTECTED]
When a socket changes to a timewait socket, the network namespace
is not copied from the original socket.
Here we hold a usage reference, not the ref count on the network
namespace, so the network namespace will be freed either the usage
reference is not 0
From: Daniel Lezcano [EMAIL PROTECTED]
Denis Lunev spotted that if we take a reference to the network namespace
with the timewait sockets, we will need to wait for their expiration to
have the network namespace freed. This is a waste of time, the timewait
sockets are for avoiding to receive
Denis V. Lunev wrote:
Sorry for a delay in answer. A was ill last three days.
Some stylistic comments inside
Daniel Lezcano wrote:
From: Daniel Lezcano [EMAIL PROTECTED]
The network namespace cleanup will remove all timewait sockets
related to it because there are pointless.
The problem
Denis V. Lunev wrote:
Daniel Lezcano wrote:
From: Daniel Lezcano [EMAIL PROTECTED]
Denis Lunev spotted that if we take a reference to the network namespace
with the timewait sockets, we will need to wait for their expiration to
have the network namespace freed. This is a waste of time
Pavel Emelyanov wrote:
Cedric Le Goater wrote:
Cedric Le Goater wrote:
Serge E. Hallyn wrote:
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
Hi, guys!
I've noticed that compiling out all the core related to
cloning and cleaning the new namespace saves us more than
a Kbyte (!) from the
From: Daniel Lezcano [EMAIL PROTECTED]
The network namespace cleanup will remove all timewait sockets
related to it because there are pointless.
The problem is we need to browse the established hash table and
for that we need to take the lock. For each timesocket we call
inet_deschedule
Denis Lunev spotted that using a reference to the network namespace
with the timewait sockets will be a waste of time because they
are pointless while we will remove the network stack at network
namespace exit.
The following patches do the following:
- fix missing network namespace
From: Daniel Lezcano [EMAIL PROTECTED]
Denis Lunev spotted that if we take a reference to the network namespace
with the timewait sockets, we will need to wait for their expiration to
have the network namespace freed. This is a waste of time, the timewait
sockets are for avoiding to receive
Eric W. Biederman wrote:
Denis V. Lunev [EMAIL PROTECTED] writes:
Daniel Lezcano wrote:
This place is a very tricky, indeed. If we keep the namespace until
timewait bucket death - we'll keep the namespace alive at least 5
_minutes_ after all process death.
Yes, that's right. And for me
Denis V. Lunev wrote:
Eric W. Biederman wrote:
Sockets need to get a reference to their network namespace,
or possibly a simple hold if someone registers on the network
namespace notifier and will free the sockets when the namespace
is going to be destroyed.
Signed-off-by: Eric W. Biederman
Stephen Hemminger wrote:
On Mon, 17 Sep 2007 15:45:11 +0200
[EMAIL PROTECTED] wrote:
From: Daniel Lezcano [EMAIL PROTECTED]
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a struct net_device
David Miller wrote:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 08 Sep 2007 15:20:36 -0600
This patch makes /proc/net per network namespace. It modifies the global
variables proc_net and proc_net_stat to be per network namespace.
The proc_net file helpers are modified to take a
David Miller wrote:
From: [EMAIL PROTECTED]
Date: Wed, 12 Sep 2007 14:38:12 +0200
From: Daniel Lezcano [EMAIL PROTECTED]
Add the appropriate EXPORT_SYMBOLS for proc_net_create,
proc_net_fops_create and proc_net_remove to fix errors when
compiling allmodconfig
Signed-off-by: Mark Nelson
Eric W. Biederman wrote:
Ok just to keep everyone in sync.
I just uploaded a version of my netns tree up to kernel.org rebased
on top of what David Miller has just merged.
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-netns.git#netns/v2.6.23-rc5netns45
Once things have
Eric W. Biederman wrote:
[EMAIL PROTECTED] writes:
The kernel compilation fails with allnoconfig with an unresolved to init_net.
I tryed to figure out how to fix that. The problem is raised because the
init_net
variable is defined as extern in net_namespace.h while the variable is declared
in
Serge E. Hallyn wrote:
Quoting Daniel Lezcano ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
From: Daniel Lezcano [EMAIL PROTECTED]
For the moment, I only made this patch for the RFC. It shows how simple
it is
to hook different socket syscalls
Serge E. Hallyn wrote:
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
Paul Menage mentionned, a few weeks ago, he wanted a bind filtering
for containers. Here it is :)
The following patches are a proposition to bring IP isolation to a container.
After looking more closely at the code I
Serge E. Hallyn wrote:
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
From: Daniel Lezcano [EMAIL PROTECTED]
For the moment, I only made this patch for the RFC. It shows how simple it is
to hook different socket syscalls. This patch denies bind to any addresses
which are not in the container
Hi Paul,
I was playing with the container filesystem (very nice) and I fall
inside a kbug.
I did the following:
mkdir /dev/container
mount -t container -o cpuset cpuset /dev/container
cd /dev/container/
mkdir Charlie
cd Charlie
echo $$
Denis V. Lunev wrote:
[EMAIL PROTECTED] wrote:
From: Daniel Lezcano [EMAIL PROTECTED]
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a struct net_device, hopefully
making maintenance easier
Pavel Emelianov wrote:
Cedric Le Goater wrote:
Badari Pulavarty wrote:
On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
This is submition for inclusion of hierarchical, not kconfig
configurable, zero overheaded ;) pid namespaces.
Not able to boot my ppc64 machine with the patchset
Benjamin Thery wrote:
Following a discussion we had at OLS concerning L2 network namespace
performances and how the new macvlan driver could potentially improve
them, I've ported the macvlan patchset on top of Eric's net namespace
patchset on 2.6.22-rc4-mm2.
A little bit of history:
Some
Hi all,
The network namespace patchset has been ported to 2.6.21-mm2.
They are still some issues but we are on it, for this reason the
patchset is named netns1-beta1.
The patchset can be found here :
http://lxc.sourceforge.net/patches/2.6.21/2.6.21-mm2-netns1-beta1/
Documentation can be
Serge E. Hallyn wrote:
Quoting Carl-Daniel Hailfinger ([EMAIL PROTECTED]):
On 11.06.2007 19:05, Serge E. Hallyn wrote:
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
should we continue to use /proc ? or switch to some other mechanisms
like getnetlink (taskstats) to map kernel structures.
We
for now this seems the right approach.
Signed-off-by: Daniel Lezcano [EMAIL PROTECTED]
Acked-by: Serge E. Hallyn [EMAIL PROTECTED]
(Or whatever tag they decide over on lkml that I should be using :)
thanks,
-serge
PS - I won't be acking other patches bc I just haven't looked
David Miller wrote:
From: Pavel Emelianov [EMAIL PROTECTED]
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
I would suggest
Pavel Emelianov wrote:
Daniel Lezcano wrote:
Pavel Emelianov wrote:
Eric W. Biederman wrote:
Pavel Emelianov [EMAIL PROTECTED] writes:
That's how OpenVZ sees the pid namespaces.
The main idea is that kernel keeps operating with tasks pid
as it did before
Pavel Emelianov wrote:
Eric W. Biederman wrote:
Pavel Emelianov [EMAIL PROTECTED] writes:
That's how OpenVZ sees the pid namespaces.
The main idea is that kernel keeps operating with tasks pid
as it did before, but each task obtains one more pid for each
pid type - the virtual pid.
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used as is as well.
Eric
Hi,
Eric Biederman has posted a few weeks ago a RFC-patchset concerning the
network namespace.
I ported it to the 2.6.20 kernel and uploaded the patchset to
http://lxc.sourceforge.net/network.php
For the part I had to used (TCP/UDP-IPV4 with usual ethernet device), I
found the patchset pretty
Hi,
as suggested Rick, I added the Service Demand results to the matrix.
Cheers.
Hi,
I did some benchmarking on the existing L2 network namespaces.
These patches are included in the lxc patchset at:
http://lxc.sourceforge.net/patches/2.6.20
The lxc7 patchset series
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
3. General observations
---
The objective to have no performances degrations, when the network
namespace is off in the kernel, is reached in both solutions.
When the network is used outside
Hi,
I did some benchmarking on the existing L2 network namespaces.
These patches are included in the lxc patchset at:
http://lxc.sourceforge.net/patches/2.6.20
The lxc7 patchset series contains Dmitry's patchset
The lxc8 patchset series contains Eric's patchset
Here are the following
Herbert Poetzl wrote:
On Wed, Mar 28, 2007 at 12:16:34AM +0200, Daniel Lezcano wrote:
Hi,
[ cut ]
3. General observations
---
The objective to have no performances degrations, when the network
namespace is off in the kernel, is reached in both solutions.
When
Herbert Poetzl wrote:
On Tue, Mar 20, 2007 at 09:53:01PM +0100, Cedric Le Goater wrote:
All,
We've been gathering, porting and testing a whole bunch of patchsets
related to namespaces, containers and resource management in what
we call the -lxc patchset.
great!
[ cut ]
*
Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
Hi Herbert,
I played with the L2 namespace patchset from Eric Biederman, I did some
benchmarking with netperf:
With 2 hosts, Intel EM64T bipro HT / 2,4 GHz , 4Go ram and GB network.
Host A is running the netserver
Eric W. Biederman wrote:
[ cut ]
Dmitry? Daniel? What do you think.
Hi Eric,
I agree with all the points you presented but I am still 50/50 for both
approaches.
The major argument in favor of the explicit parameter is that it allows
to keep track of the network namespace. But the
Eric W. Biederman wrote:
[ cut ]
Dmitry? Daniel? What do you think.
Hi Eric,
I agree with all the points you presented but I am still 50/50 for both
approaches.
The major argument in favor of the explicit parameter is that it allows
to keep track of the network namespace. But the argument
Hi Eric,
Do you plan to propose to merge into mainline your patchset ?
Shouldn't we ask netdev guys what they think about the explicit network
namespace parameter into function you did versus the implicit network
context using the push_net_ns/pop_net_ns function ?
-- Daniel
Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This patch introduces NETIF_F_NETNS_LOCAL a flag to indicate
a network device is local to a single network namespace and
should never be moved. Useful for pseudo devices that we
need an instance in each network
Eric W. Biederman wrote:
From: Eric W. Biederman [EMAIL PROTECTED] - unquoted
This patch allows you to create a new network namespace
using sys_clone(...).
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/sched.h|1 +
kernel/nsproxy.c | 11
501 - 543 of 543 matches
Mail list logo
