From mboxrd@z Thu Jan 1 00:00:00 1970 From: Veaceslav Falico Subject: Re: [net] net_sched: make dev_trans_start return vlan's real dev trans_start Date: Sat, 3 Aug 2013 21:09:18 +0200 Message-ID: <20130803190918.GA11976@redhat.com> References: <1375542471-22739-1-git-send-email-nikolay@redhat.com> <20130803170733.GA10218@redhat.com> <20130803.115228.1509916868029010372.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Cc: nikolay@redhat.com, netdev@vger.kernel.org, fubar@us.ibm.com, jhs@mojatatu.com To: David Miller Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52254 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751970Ab3HCTdp (ORCPT ); Sat, 3 Aug 2013 15:33:45 -0400 Content-Disposition: inline In-Reply-To: <20130803.115228.1509916868029010372.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: On Sat, Aug 03, 2013 at 11:52:28AM -0700, David Miller wrote: >From: Veaceslav Falico >Date: Sat, 3 Aug 2013 19:07:33 +0200 > >> On Sat, Aug 03, 2013 at 05:07:51PM +0200, nikolay@redhat.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.