From: Kirill Korotaev <dev@sw.ru>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Patrick McHardy <kaber@trash.net>, Jeff Garzik <jeff@garzik.org>,
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>,
netdev@vger.kernel.org, jamal <hadi@cyberus.ca>,
Linux Containers <containers@lists.osdl.org>,
Ben Greear <greearb@candelatech.com>,
Stephen Hemminger <shemminger@linux-foundation.org>,
David Miller <davem@davemloft.net>
Subject: Re: [RFD] L2 Network namespace infrastructure
Date: Thu, 28 Jun 2007 18:53:01 +0400 [thread overview]
Message-ID: <4683CB4D.90909@sw.ru> (raw)
In-Reply-To: <m1bqf6a8rd.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Patrick McHardy <kaber@trash.net> writes:
>
>
>>Eric W. Biederman wrote:
>>
>>>-- The basic design
>>>
>>>There will be a network namespace structure that holds the global
>>>variables for a network namespace, making those global variables
>>>per network namespace.
>>>
>>>One of those per network namespace global variables will be the
>>>loopback device. Which means the network namespace a packet resides
>>>in can be found simply by examining the network device or the socket
>>>the packet is traversing.
>>>
>>>Either a pointer to this global structure will be passed into
>>>the functions that need to reference per network namespace variables
>>>or a structure that is already passed in (such as the network device)
>>>will be modified to contain a pointer to the network namespace
>>>structure.
>>
>>
>>I believe OpenVZ stores the current namespace somewhere global,
>>which avoids passing the namespace around. Couldn't you do this
>>as well?
>
>
> It sucks. Especially in the corner cases. Think macvlan
> with the real network device in one namespace and the ``vlan''
> device in another device.
sorry, what's the problem here? I don't see a single problem here
related to the global current context.
> The implementation of a global is also pretty a little questionable.
> Last I looked it didn't work on the transmit path at all and
> interesting on the receive path.
>
> Further and fundamentally all a global achieves is removing the need
> for the noise patches where you pass the pointer into the various
> functions. For long term maintenance it doesn't help anything.
this is not 100% true.
Having global context also helps:
1. to account for time spent in network processing or some other activity
(like IRQ handling) to appropriate namespace.
2. it is really usefull and helpfull for functions like printk() with virtualized
syslog buffer. Otherwise you would need to find a context in every place where
namespace private message should be printed.
Actually it is the same natural as the 'current' which is global,
but could be passed from entry.S instead to every function which needs it.
OVZ experience just tells me that this helps to avoid all this noise
and not harder to work with then with 'current'. But it's up to you.
Thanks,
Kirill
next prev parent reply other threads:[~2007-06-28 14:53 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-22 19:39 [RFD] L2 Network namespace infrastructure Eric W. Biederman
2007-06-22 21:22 ` [PATCH] net: Basic network " Eric W. Biederman
2007-06-23 10:40 ` [RFD] L2 Network " Patrick McHardy
2007-06-23 15:20 ` Ben Greear
2007-06-23 17:26 ` Eric W. Biederman
2007-06-23 20:09 ` Ben Greear
2007-06-23 20:39 ` Eric W. Biederman
2007-06-23 20:44 ` Ben Greear
2007-06-23 17:26 ` Stephen Hemminger
2007-06-23 17:55 ` Eric W. Biederman
2007-06-23 20:03 ` Ben Greear
2007-06-27 14:41 ` [Devel] " Kirill Korotaev
2007-06-23 17:19 ` Eric W. Biederman
2007-06-23 18:00 ` Patrick McHardy
2007-06-23 19:08 ` Eric W. Biederman
2007-06-23 20:19 ` Carl-Daniel Hailfinger
2007-06-23 20:31 ` Eric W. Biederman
2007-06-23 20:57 ` David Miller
2007-06-23 21:22 ` Benny Amorsen
2007-06-24 5:39 ` David Miller
2007-06-23 21:41 ` Eric W. Biederman
2007-06-24 5:45 ` David Miller
2007-06-24 12:58 ` Eric W. Biederman
2007-06-25 2:39 ` David Miller
2007-06-26 15:32 ` Eric W. Biederman
2007-06-23 22:15 ` Jeff Garzik
2007-06-23 22:56 ` Eric W. Biederman
2007-06-24 1:28 ` Jeff Garzik
2007-06-25 15:23 ` Serge E. Hallyn
2007-06-27 15:38 ` [Devel] " Kirill Korotaev
2007-06-24 5:48 ` David Miller
2007-06-24 10:25 ` Benny Amorsen
2007-06-24 12:38 ` Eric W. Biederman
2007-06-25 15:11 ` Serge E. Hallyn
2007-06-28 14:53 ` Kirill Korotaev [this message]
2007-06-27 14:39 ` [Devel] " Kirill Korotaev
2007-06-27 14:45 ` Patrick McHardy
2007-06-27 14:56 ` Ben Greear
2007-06-28 13:12 ` Kirill Korotaev
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=4683CB4D.90909@sw.ru \
--to=dev@sw.ru \
--cc=containers@lists.osdl.org \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=greearb@candelatech.com \
--cc=hadi@cyberus.ca \
--cc=jeff@garzik.org \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
--cc=yoshfuji@linux-ipv6.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;
as well as URLs for NNTP newsgroup(s).