All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Mark Smith
	<nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>,
	greearb@candelatech.com, David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, shemminger@linux-foundation.org
Subject: Re: MACVLANs really best solution? How about a bridge with multiple bridge virtual interfaces?
Date: Mon, 09 Mar 2009 16:53:16 +0100	[thread overview]
Message-ID: <49B53B6C.7060400@trash.net> (raw)
In-Reply-To: <m13admbsuk.fsf@fess.ebiederm.org>

Eric W. Biederman wrote:
> There are two tricky parts.
> 
> One problem is that macvlans and the primary hardware device share the
> same transmit queue.  So when I have a broadcast packet on the primary
> devices queue I don't know if I have already sent it out to the
> macvlan devices or not.

So its about receiving packets on macvlan when transmitting on the
real device? That sounds like a really hard problem that would probably
indeed be better solved by a bridge.

If its just about whether the packet should be sent out by macvlan
to the wire as well, I'd say yes since thats what two real devices
would have done.

> The second problem is that when I transmit a multicast packet and I
> have a local listener.  I believe replicating the packet both at the
> ip layer and at the ethernet layer will result in receiving the packet
> locally twice.
> 
> I'm not certain we need to solve the second problem as having two physical
> interfaces plugged into a switch will have the same problem.

Agreed.

> The first problem is all about how do we deliver packets everywhere except self.

I think "except self should just mean "not to the originating virtual
device".

  reply	other threads:[~2009-03-09 15:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-07 10:45 MACVLANs really best solution? How about a bridge with multiple bridge virtual interfaces? (was Re: [PATCH] macvlan: Support creating macvlans from macvlans) Mark Smith
2009-03-07 16:30 ` Ben Greear
2009-03-07 18:13   ` Eric W. Biederman
2009-03-07 22:32     ` Mark Smith
2009-03-08 16:54       ` Ben Greear
2009-03-09  1:14         ` Mark Smith
2009-03-09 13:31 ` Patrick McHardy
2009-03-09 14:56   ` Eric W. Biederman
2009-03-09 15:02     ` Patrick McHardy
2009-03-09 15:48       ` MACVLANs really best solution? How about a bridge with multiple bridge virtual interfaces? Eric W. Biederman
2009-03-09 15:53         ` Patrick McHardy [this message]
2009-03-09 16:34           ` Eric W. Biederman
2009-03-09 16:45             ` Patrick McHardy
2009-03-09 18:58               ` Ben Greear
2009-03-09 21:17                 ` Eric W. Biederman
2009-03-09 21:23                   ` Ben Greear
2009-03-09 18:33         ` Brian Haley
2009-03-09 18:54         ` Ben Greear

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=49B53B6C.7060400@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=greearb@candelatech.com \
    --cc=nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.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.