[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1344983624.2690.77.camel@bwh-desktop.uk.solarflarecom.com>
Date: Tue, 14 Aug 2012 23:33:44 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>,
<edumazet@...gle.com>, <faisal.latif@...el.com>,
<roland@...nel.org>, <sean.hefty@...el.com>,
<hal.rosenstock@...il.com>, <fubar@...ibm.com>,
<andy@...yhouse.net>, <divy@...lsio.com>,
<jitendra.kalsaria@...gic.com>, <sony.chacko@...gic.com>,
<linux-driver@...gic.com>, <kaber@...sh.net>,
<ursula.braun@...ibm.com>, <blaschka@...ux.vnet.ibm.com>,
<linux390@...ibm.com>, <shemminger@...tta.com>,
<therbert@...gle.com>, <xiyou.wangcong@...il.com>,
<joe@...ches.com>, <gregory.v.rose@...el.com>,
<john.r.fastabend@...el.com>, <linux-rdma@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-s390@...r.kernel.org>,
<bridge@...ts.linux-foundation.org>, <fbl@...hat.com>
Subject: Re: [patch net-next v2 01/15] net: introduce upper device lists
On Tue, 2012-08-14 at 17:05 +0200, Jiri Pirko wrote:
> This lists are supposed to serve for storing pointers to all upper devices.
> Eventually it will replace dev->master pointer which is used for
> bonding, bridge, team but it cannot be used for vlan, macvlan where
> there might be multiple upper present. In case the upper link is
> replacement for dev->master, it is marked with "master" flag.
Something I found interesting is that the dev->master pointer and now
netdev_master_upper_dev_get{,_rcu}() are hardly used by the stackled
drivers that set the master. They also have to set an rx_handler on the
lower device (which is itself mutually exclusive) which gets its own
context pointer (rx_handler_data).
Instead, the master pointer is mostly used by device drivers to find out
about a bridge or bonding device above *their* devices. And that seems
to work only for those specific device drivers, not e.g. openvswitch or
team. I wonder if we could find a better way to encapsulate the things
they want do do, in a later step (not holding up this change!).
[...]
> +static int __netdev_upper_dev_link(struct net_device *dev,
> + struct net_device *upper_dev, bool master)
> +{
> + struct netdev_upper *upper;
> +
> + ASSERT_RTNL();
> +
> + if (dev == upper_dev)
> + return -EBUSY;
> + /*
> + * To prevent loops, check if dev is not upper device to upper_dev.
> + */
> + if (__netdev_has_upper_dev(upper_dev, dev, true))
> + return -EBUSY;
[...]
I think we will also need to limit the depth of the device stack so we
don't run out of stack space here. __netif_receive() implements a kind
of tail recursion whenever a packet is passed up, but
__netdev_has_upper_dev() can't avoid doing real recursion (without the
addition of a flag to net_device so it can mark its progress).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists