All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
	netdev@vger.kernel.org, bridge@linux-foundation.org,
	Denis Lunev <den@openvz.org>
Subject: Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature
Date: Fri, 26 Feb 2010 10:01:02 -0800	[thread overview]
Message-ID: <20100226100102.0d52c6e9@nehalam> (raw)
In-Reply-To: <4B88076F.8030302@openvz.org>

On Fri, 26 Feb 2010 20:39:59 +0300
Pavel Emelyanov <xemul@openvz.org> wrote:

> Cyrill Gorcunov wrote:
> > On Fri, Feb 26, 2010 at 08:18:43AM -0800, Stephen Hemminger wrote:
> >> Looking back at this. What if the API was simpler:
> 
> Thanks for the reply, Stephen!
> 
> >> Why not:
> >>   1. Setup bridge (and any other interfaces except eth0); includes bringing br0 up
> >>   2. Add eth0 to bridge with new flag to inherit
> >>        a. brctl addif br0 eth0 inherit
> >>
> >> Inherit functionality would need to move address (Ether, IP, IPv6)
> >> and routes from eth0 to br0.
> >> I will see about doing it as much as possible in userspace.
> >>
> 
> Solution is good, but we'll have to reconfigure netfilter matches
> that check for device name/ifindex and restore all this back when
> deleting eth0 from br0.

Netfilter is outside of this, and can't really migrate easily.

> Maybe it's better to implement it on the kernel side by sending a 
> netdev notification and letting the subsystem reconfigure themselves?
> 
> And what can we do with existing TCP connections bound to a device?
> 

TCP connections are never really bound to device. TCP routing is
flexible; if packets can get through, it doesn't care.

-- 

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
	bridge@linux-foundation.org, netdev@vger.kernel.org,
	Denis Lunev <den@openvz.org>
Subject: Re: [RFC 0/5] bridge - introduce via_phys_dev feature
Date: Fri, 26 Feb 2010 10:01:02 -0800	[thread overview]
Message-ID: <20100226100102.0d52c6e9@nehalam> (raw)
In-Reply-To: <4B88076F.8030302@openvz.org>

On Fri, 26 Feb 2010 20:39:59 +0300
Pavel Emelyanov <xemul@openvz.org> wrote:

> Cyrill Gorcunov wrote:
> > On Fri, Feb 26, 2010 at 08:18:43AM -0800, Stephen Hemminger wrote:
> >> Looking back at this. What if the API was simpler:
> 
> Thanks for the reply, Stephen!
> 
> >> Why not:
> >>   1. Setup bridge (and any other interfaces except eth0); includes bringing br0 up
> >>   2. Add eth0 to bridge with new flag to inherit
> >>        a. brctl addif br0 eth0 inherit
> >>
> >> Inherit functionality would need to move address (Ether, IP, IPv6)
> >> and routes from eth0 to br0.
> >> I will see about doing it as much as possible in userspace.
> >>
> 
> Solution is good, but we'll have to reconfigure netfilter matches
> that check for device name/ifindex and restore all this back when
> deleting eth0 from br0.

Netfilter is outside of this, and can't really migrate easily.

> Maybe it's better to implement it on the kernel side by sending a 
> netdev notification and letting the subsystem reconfigure themselves?
> 
> And what can we do with existing TCP connections bound to a device?
> 

TCP connections are never really bound to device. TCP routing is
flexible; if packets can get through, it doesn't care.

-- 

  reply	other threads:[~2010-02-26 18:01 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-11 11:46 [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature Cyrill Gorcunov
2009-05-11 11:46 ` Cyrill Gorcunov
2009-05-11 11:46 ` [Bridge] [RFC 1/5] net: bridge - use is_multicast_ether_addr helper Cyrill Gorcunov
2009-05-11 11:46   ` Cyrill Gorcunov
2009-05-19 22:18   ` [Bridge] " Stephen Hemminger
2009-05-19 22:18     ` Stephen Hemminger
2009-05-11 11:46 ` [Bridge] [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   ` Cyrill Gorcunov
2009-05-11 11:46 ` [Bridge] [RFC 3/5] net: sk_buff - introduce br_seen field to mark skb issued by a bridge Cyrill Gorcunov
2009-05-11 11:46   ` Cyrill Gorcunov
2009-05-11 11:46 ` [Bridge] [RFC 4/5] net: dev.c - introduce br_hard_xmit_hook Cyrill Gorcunov
2009-05-11 11:46   ` Cyrill Gorcunov
2009-05-11 11:46 ` [Bridge] [RFC 5/5] net: bridge - handle via_phys_dev feature on a bridge level Cyrill Gorcunov
2009-05-11 11:46   ` Cyrill Gorcunov
2009-05-11 13:01   ` [Bridge] " 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  5:30   ` Daniel Robbins
2009-05-12  6:19   ` Cyrill Gorcunov
2009-05-12  6:19     ` Cyrill Gorcunov
2009-05-12  7:02     ` Daniel Robbins
2009-05-12  7:02       ` Daniel Robbins
2009-05-12 16:24       ` Cyrill Gorcunov
2009-05-12 16:24         ` Cyrill Gorcunov
2009-05-12 17:07         ` Daniel Robbins
2009-05-12 17:07           ` Daniel Robbins
2009-05-12 17:21           ` Cyrill Gorcunov
2009-05-12 17:21             ` Cyrill Gorcunov
2009-05-19 22:21 ` Stephen Hemminger
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             ` [Bridge] " Stephen Hemminger
2010-02-26 16:18               ` Stephen Hemminger
2010-02-26 16:51               ` [Bridge] " Cyrill Gorcunov
2010-02-26 16:51                 ` Cyrill Gorcunov
2010-02-26 17:39                 ` [Bridge] " Pavel Emelyanov
2010-02-26 17:39                   ` Pavel Emelyanov
2010-02-26 18:01                   ` Stephen Hemminger [this message]
2010-02-26 18:01                     ` Stephen Hemminger
2010-02-26 18:08                     ` [Bridge] " David Miller
2010-02-26 18:08                       ` David Miller
2010-02-26 18:30                       ` [Bridge] " Stephen Hemminger
2010-02-26 18:30                         ` Stephen Hemminger
2010-02-26 18:40                         ` [Bridge] " Ben Greear
2010-02-26 18:40                           ` Ben Greear
2010-02-26 18:49                           ` [Bridge] " Stephen Hemminger
2010-02-26 18:49                             ` Stephen Hemminger
2010-02-26 21:16                             ` [Bridge] " Pavel Emelyanov
2010-02-26 21:16                               ` Pavel Emelyanov
2010-02-26 18:55                         ` [Bridge] " Cyrill Gorcunov
2010-02-26 18:55                           ` Cyrill Gorcunov
2010-02-26 19:01                         ` [Bridge] " David Miller
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=20100226100102.0d52c6e9@nehalam \
    --to=shemminger@linux-foundation.org \
    --cc=bridge@linux-foundation.org \
    --cc=den@openvz.org \
    --cc=gorcunov@gmail.com \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.