[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130803190918.GA11976@redhat.com>
Date: Sat, 3 Aug 2013 21:09:18 +0200
From: Veaceslav Falico <vfalico@...hat.com>
To: David Miller <davem@...emloft.net>
Cc: nikolay@...hat.com, netdev@...r.kernel.org, fubar@...ibm.com,
jhs@...atatu.com
Subject: Re: [net] net_sched: make dev_trans_start return vlan's real dev
trans_start
On Sat, Aug 03, 2013 at 11:52:28AM -0700, David Miller wrote:
>From: Veaceslav Falico <vfalico@...hat.com>
>Date: Sat, 3 Aug 2013 19:07:33 +0200
>
>> On Sat, Aug 03, 2013 at 05:07:51PM +0200, nikolay@...hat.com wrote:
>> ...snip...
>>>+ while (is_vlan_dev(dev))
>>>+ dev = vlan_dev_real_dev(dev);
>>
>> While at it - I've checked a few users (mainly network drivers) of
>> vlan_dev_real_dev(dev) and they all rely on that the return device
>> would be the *real* device, but not another vlan.
>
>Did you find any cases that want the device under the VLAN,
>whether it is a non-vlan device or not?
Not really. All of the cases seem to explicitly call it to get a non-vlan
device, and not the purely 'underlying' one.
Another point is that they won't work properly with QinQ... cause the
majority of callers are searching for their own device. Or bonding, as in
netxen that Nik mentioned. And they will find yet another vlan device.
So either QinQ isn't really that used or I'm missing something...
>
>> So maybe we should move this while loop to vlan_dev_real_dev()
>> instead?
>
>Perhaps. As per above, we may also need the one-level demux
>helper too, something like "vlan_dev_slave(dev)".
I haven't found any usage for it, tbh. Only the vlan code itself might
benefit from it, but it already uses the vlan_dev_priv(dev)->real_dev, and
not the vlan_dev_real_dev(), which is used by drivers.
--
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