netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Ben Greear <greearb@candelatech.com>
Cc: Patrick McHardy <kaber@trash.net>,
	Mark Smith
	<nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>,
	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 14:17:23 -0700	[thread overview]
Message-ID: <m17i2y5rbw.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <49B566DF.3040603@candelatech.com> (Ben Greear's message of "Mon\, 09 Mar 2009 11\:58\:39 -0700")

Ben Greear <greearb@candelatech.com> writes:

> Patrick McHardy wrote:
>
>>> Now that I think about it we could call ndo_start_xmit directly
>>> from the macvlan code, and bypass whatever hook we use to
>>> intercept packets going out the normal device it should not
>>> be too difficult.
>>
>> We don't intercept packets on TX, they have to be explicitly delivered
>> to macvlan.
>
> It might suck for performance, but mac-vlan could register an 'ALL' protocol
> on the physical dev, similar to tcp-dump, to grab pkts on tx and pass the
> ones it cares about back up to the vlans?

I like that idea.  At least for prototyping.

I wonder if pkt_type all could be have a per interface optimized variant.

> I'd want run-time control to disable any of these costly options for those that
> don't need it, however.

If well implemented it should not be more expensive than the ingress path where
we already have, and where we already do that.  Unless your traffic is highly
assymmetric.

Eric

  reply	other threads:[~2009-03-09 21:17 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
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 [this message]
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=m17i2y5rbw.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=davem@davemloft.net \
    --cc=greearb@candelatech.com \
    --cc=kaber@trash.net \
    --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 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).