[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1bpiz8k1x.fsf@fess.ebiederm.org>
Date: Wed, 18 Nov 2009 15:55:38 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Arnd Bergmann <arnd@...db.de>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
David Miller <davem@...emloft.net>,
Stephen Hemminger <shemminger@...tta.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Patrick McHardy <kaber@...sh.net>,
Patrick Mullaney <pmullaney@...ell.com>,
Edge Virtual Bridging <evb@...oogroups.com>,
Anna Fischer <anna.fischer@...com>,
bridge@...ts.linux-foundation.org,
virtualization@...ux-foundation.com,
Jens Osterkamp <jens@...ux.vnet.ibm.com>,
Gerhard Stenzel <gerhard.stenzel@...ibm.com>
Subject: Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
Arnd Bergmann <arnd@...db.de> writes:
> On Wednesday 18 November 2009 14:37:50 Eric W. Biederman wrote:
>> Arnd Bergmann <arnd@...db.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists