netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Daniel Robbins <drobbins@funtoo.org>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
	netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
	davem@davemloft.net, xemul@openvz.org
Subject: Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature
Date: Tue, 12 May 2009 20:24:32 +0400	[thread overview]
Message-ID: <20090512162432.GA12820@lenovo> (raw)
In-Reply-To: <de7adc5e0905120002o7f19a1eepe0397d698c08ce97@mail.gmail.com>

[Daniel Robbins - Tue, May 12, 2009 at 01:02:01AM -0600]
|
| Is this functionality useful for OpenVZ? Do people need the ability to
| do this? Why/when is it necessary for me to be able to add eth0 to a
| bridge remotely?
| 

As far as I know (fix me if I'm wrong) you're not able to configure
bridge remotely from the scratch via active port (say eth0) without
interrupting the session and recreating routing table. Of course you
could have a script which will do all work for you. (or you could
be having a machine with 3/4/5/10 NIC's and one of them could be
just reserved to be used remote access only with proper routing
table, etc...). But in case if all nics are to be used as bridge
ports and you still need to access such a machine remotely i believe
via_phys_dev could be our friend :)

So, Daniel, i think the right question is -- do I ever need to
configure/setup bridge remotely? I suppose yes, it happens.
(at least I had a machine with lack of input device except a few
 NICs :-)

|
| I don't quite (yet) understand the usefulness of this feature. You
| would still be very limited in what you can change with the network if
| you are remote, right? That's why I don't quite understand the benefit
| of this feature. How are you planning to use it? When I set up my
| OpenVZ systems, I like to get the overall network/bridge configuration
| perfect so that I don't need to make major changes when I am remote.
|

This feature already was in OpenVZ 2.6.24 kernel. I'm more intiresting in
usefulness of this feature for the mainline. (in short -- we use it for bridging
VEs with eth0 as a master device so all works without needing to
reconfigure routing table). Moreover, since bridge already support
namespacing the feature could be usefull for lxc as well (though
didn't check to be fair).

| 
| Again, I am not an expert so I am asking purely for my own curiosity.
| I support the idea of making networking more flexible, but I do not
| see this particular step addressed by the patch as a common need. That
| may be due to my own lack of understanding.
| 

That is why it's RFC so people could decide should it be included
into mainline or not. Worth it so or not.

|
| I am a big fan of OpenVZ though, so if it helps OpenVZ in some way,
| I'd like to know about it :)
|

Yes it helps to bridge VE's without reconstructing routing table
on HW node.

| 
| -Daniel
| 
 
	-- Cyrill

  reply	other threads:[~2009-05-12 16:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-11 11:46 [RFC 0/5] bridge - introduce via_phys_dev feature Cyrill Gorcunov
2009-05-11 11:46 ` [RFC 1/5] net: bridge - use is_multicast_ether_addr helper Cyrill Gorcunov
2009-05-19 22:18   ` Stephen Hemminger
2009-05-11 11:46 ` [RFC 2/5] net: bridge - add managing of BRCTL_SET_VIA_PHYS_DEV and BRCTL_SET_MASTER_DEV Cyrill Gorcunov
2009-05-11 11:46 ` [RFC 3/5] net: sk_buff - introduce br_seen field to mark skb issued by a bridge Cyrill Gorcunov
2009-05-11 11:46 ` [RFC 4/5] net: dev.c - introduce br_hard_xmit_hook Cyrill Gorcunov
2009-05-11 11:46 ` [RFC 5/5] net: bridge - handle via_phys_dev feature on a bridge level Cyrill Gorcunov
2009-05-11 13:01   ` Cyrill Gorcunov
2009-05-12  5:30 ` [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature Daniel Robbins
2009-05-12  6:19   ` Cyrill Gorcunov
2009-05-12  7:02     ` Daniel Robbins
2009-05-12 16:24       ` Cyrill Gorcunov [this message]
2009-05-12 17:07         ` Daniel Robbins
2009-05-12 17:21           ` Cyrill Gorcunov
2009-05-19 22:21 ` Stephen Hemminger
     [not found]   ` <20090520192726.GF4968@lenovo>
     [not found]     ` <20090520131225.03b7715a@nehalam>
     [not found]       ` <20090521180805.GC4932@lenovo>
     [not found]         ` <20090521140504.1865883b@nehalam>
     [not found]           ` <20090522201850.GF5354@lenovo>
2010-02-26 16:18             ` Stephen Hemminger
2010-02-26 16:51               ` Cyrill Gorcunov
2010-02-26 17:39                 ` Pavel Emelyanov
2010-02-26 18:01                   ` Stephen Hemminger
2010-02-26 18:08                     ` David Miller
2010-02-26 18:30                       ` Stephen Hemminger
2010-02-26 18:40                         ` Ben Greear
2010-02-26 18:49                           ` Stephen Hemminger
2010-02-26 21:16                             ` Pavel Emelyanov
2010-02-26 18:55                         ` Cyrill Gorcunov
2010-02-26 19:01                         ` David Miller
2010-02-26 16:52               ` [Bridge] " richardvoigt
2010-02-26 17:25                 ` Stephen Hemminger

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=20090512162432.GA12820@lenovo \
    --to=gorcunov@gmail.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=drobbins@funtoo.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.org \
    --cc=xemul@openvz.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).