netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	David Miller <davem@davemloft.net>,
	Stephen Hemminger <shemminger@vyatta.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Patrick McHardy <kaber@trash.net>,
	Patrick Mullaney <pmullaney@novell.com>,
	Edge Virtual Bridging <evb@yahoogroups.com>,
	Anna Fischer <anna.fischer@hp.com>,
	bridge@lists.linux-foundation.org,
	virtualization@linux-foundation.com,
	Jens Osterkamp <jens@linux.vnet.ibm.com>,
	Gerhard Stenzel <gerhard.stenzel@de.ibm.com>
Subject: Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
Date: Wed, 18 Nov 2009 15:55:38 -0800	[thread overview]
Message-ID: <m1bpiz8k1x.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <200911182332.56309.arnd@arndb.de> (Arnd Bergmann's message of "Wed\, 18 Nov 2009 23\:32\:56 +0000")

Arnd Bergmann <arnd@arndb.de> writes:

> On Wednesday 18 November 2009 14:37:50 Eric W. Biederman wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> > On Wednesday 18 November 2009, Eric Dumazet wrote:
>> >> 
>> >> Why do you drop dst here ?
>> >> 
>> >> It seems strange, since this driver specifically masks out IFF_XMIT_DST_RELEASE
>> >> in its macvlan_setup() :
>> >> 
>> >> dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
>
> It seems that we should never drop dst then. We either forward the frame to
> netif_rx or to dev_queue_xmit, and from how I read it now, we want to keep
> the dst in both cases.

When we loop back on our selves we certainly need to have dst clear because
we don't know how to cache routes through multiple network namespaces.  It
might be handy if we had those but that is a problem for another day.

>> Please copy and ideally share code with the veth driver for recycling a skb.
>> There are bunch of little things you have to do to get it right.  As I recally
>> I was missing a few details in my original patch.
>
> Are you thinking of something like the patch below? I haven't had the chance
> to test this, but one thing it does is to handle the internal forwarding
> differently from the receive path.

Yes.  That is a bit more sharing than I had anticipated, but it looks like
it works.

Eric

  reply	other threads:[~2009-11-18 23:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-17 22:39 [PATCH 0/3] macvlan: add vepa and bridge mode Arnd Bergmann
2009-11-17 22:39 ` [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices Arnd Bergmann
2009-11-18  6:30   ` Eric Dumazet
2009-11-18  9:47     ` Arnd Bergmann
2009-11-18 14:37       ` Eric W. Biederman
2009-11-18 14:44         ` Arnd Bergmann
2009-11-18 23:32         ` Arnd Bergmann
2009-11-18 23:55           ` Eric W. Biederman [this message]
2009-11-19 11:44             ` Arnd Bergmann
2009-11-19 14:47               ` Patrick McHardy
2009-11-18 10:00   ` roel kluin
2009-11-17 22:39 ` [PATCH 2/3] macvlan: implement VEPA and private mode Arnd Bergmann
2009-11-18  6:42   ` Eric Dumazet
2009-11-18  9:48     ` Arnd Bergmann
2009-11-17 22:39 ` [PATCH 3/3] macvlan: export macvlan mode through netlink Arnd Bergmann
2009-11-18  6:48   ` Eric Dumazet
2009-11-18  9:59     ` Arnd Bergmann
2009-11-19 14:38       ` Patrick McHardy
2009-11-19 14:47         ` Arnd Bergmann
2009-11-17 22:39 ` [PATCH] iplink: add macvlan options for bridge mode Arnd Bergmann
2009-12-18 13:45   ` Arnd Bergmann
2009-12-18 17:25     ` Stephen Hemminger
2009-12-18 17:37       ` Arnd Bergmann
2009-11-17 22:56 ` [PATCH 0/3] macvlan: add vepa and " Arnd Bergmann
2009-11-18  9:01 ` Mark Smith
2009-11-27 10:57 ` [PATCH, resend] iproute2/iplink: add macvlan options for " Arnd Bergmann
2009-12-26 19:24   ` 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=m1bpiz8k1x.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=anna.fischer@hp.com \
    --cc=arnd@arndb.de \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=evb@yahoogroups.com \
    --cc=gerhard.stenzel@de.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jens@linux.vnet.ibm.com \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pmullaney@novell.com \
    --cc=shemminger@vyatta.com \
    --cc=virtualization@linux-foundation.com \
    /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).