From: Nikolay Aleksandrov <nikolay@redhat.com>
To: Veaceslav Falico <vfalico@redhat.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, fubar@us.ibm.com,
jhs@mojatatu.com
Subject: Re: [PATCH net 1/2] vlan: make vlan_dev_real_dev work over stacked vlans
Date: Mon, 05 Aug 2013 10:12:38 +0200 [thread overview]
Message-ID: <51FF5E76.1090008@redhat.com> (raw)
In-Reply-To: <20130805065855.GF22756@redhat.com>
On 08/05/2013 08:58 AM, Veaceslav Falico wrote:
> On Sun, Aug 04, 2013 at 04:17:43AM +0200, Nikolay Aleksandrov wrote:
>> On 08/03/2013 10:07 PM, Nikolay Aleksandrov wrote:
<snip>
>> I have one question - why not make it possible to call vlan_dev_real_dev()
>> with any device (vlan/non-vlan) and make it return a real device in all
>> cases (e.g. if it's a non-vlan device simply return it) ?
>> In the terms of the code above - simply change:
>> struct net_device *ret = vlan_dev_priv(dev)->real_dev;
>> with
>> struct net_device *ret = dev;
>>
>> This way we'll be able to simplify calls like if (is_vlan_dev(dev)) (or the
>> flag check alternative of this) to just vlan_dev_real_dev(). The old call
>> sites of this function will still work properly.
>
> I think it'll be a bit harder to understand the callers' code. Now it
> always has the logic "wait, we might be having a vlan here, so lets verify
> if it's really a vlan and if yes - get the real device". However with this
> approach it might look like "we *really* have a vlan here - so lets get the
> real device" (because of the function name - vlan_dev_real_dev) - which is
> wrong. And it doesn't really provide any speed/size improvements - so it's
> kind of useless.
>
It's not used in fast paths, this suggestion was purely about saving some
lines and indentation levels. And you can still use it the old way if you
prefer it.
> So, unless a better function name can be found (which I can't come up with
> - dev_or_strip_vlan()? dev_devlanitize()? :) ) - I'd stay with the current
> version. Though, again, I don't have a strong opinion on this.
It's all the same to me as well, I've wasted enough time on these simple
patches so I'd rather see them in (if accepted) than argue about semantics :-)
>
>>
>> Nik
next prev parent reply other threads:[~2013-08-05 8:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-03 20:07 [PATCH net 1/2] vlan: make vlan_dev_real_dev work over stacked vlans Nikolay Aleksandrov
2013-08-03 20:07 ` [PATCH net v2 2/2] net_sched: make dev_trans_start return vlan's real dev trans_start Nikolay Aleksandrov
2013-08-03 20:12 ` Veaceslav Falico
2013-08-05 19:18 ` David Miller
2013-08-03 20:11 ` [PATCH net 1/2] vlan: make vlan_dev_real_dev work over stacked vlans Veaceslav Falico
2013-08-04 2:17 ` Nikolay Aleksandrov
2013-08-05 6:58 ` Veaceslav Falico
2013-08-05 8:12 ` Nikolay Aleksandrov [this message]
2013-08-05 19:18 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51FF5E76.1090008@redhat.com \
--to=nikolay@redhat.com \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=jhs@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=vfalico@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).