Re: [patch net-next 01/15] net: introduce upper device lists
From: Jiri Pirko <jiri@resnulli.us>
Date: 2013-01-01 01:04:09
Mon, Dec 31, 2012 at 08:22:12PM CET, shemminger@vyatta.com wrote:
On Sun, 30 Dec 2012 12:58:08 +0100 Jiri Pirko [off-list ref] wrote:quoted
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. New upper device list resolves this limitation. Also, the information stored in lists is used for preventing looping setups like "bond->somethingelse->samebond" Signed-off-by: Jiri Pirko <jiri@resnulli.us>I like the concept of knowing the topology of layered network devices. The name "upper device lists" is a little confusing to me.
Well, it's a list of devices "upper" to this one. Please provide more suitable name alternative. I can't think of any, in fact I think "upper" is pretty suitable.
Also, the amount of additional data structures and book keeping seems more than needed; but not sure how to reduce it down to the least code.
Yep, that's it. I tried to make that as slim as possible. Trimming ideas are very welcome.
For simple case of detecting loops, just using existing master
pointer is sufficient.
ethernet --> bonding --> bridge --+
^ |
| |
+-----------------+
This is the simple case of detecting if singularly linked list
is a loop.
The only device where multiple upper devices is possible seems
to be macvlan. Could the special case code be limited to there?Well, there are others, vlan for example. And the whole concept is to make this uniform and generic, to avoid specific code for specific drivers. And there are some usecases which can benefit from the upper lists, like for example drivers which need to obtain l3 address info (cxgb3, qlcnic, qeth). But in any case, I doubt that this alternative approach will lead to much smaller code footprint. I think it would be just more messy.