netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>, Vladimir Oltean <olteanv@gmail.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Yunjian Wang <wangyunjian@huawei.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net] net: Have netpoll bring-up DSA management interface
Date: Mon, 16 Nov 2020 15:20:37 -0800	[thread overview]
Message-ID: <d2dbb984-604a-ecbd-e717-2e9942fdbdaa@gmail.com> (raw)
In-Reply-To: <a8d38b5b-ae85-b1a8-f139-ae75f7c01376@gmail.com>

On 11/16/20 3:06 PM, Florian Fainelli wrote:
> On 10/20/20 6:12 PM, Jakub Kicinski wrote:
>> On Tue, 20 Oct 2020 00:19:16 +0300 Vladimir Oltean wrote:
>>> On Mon, Oct 19, 2020 at 02:03:40PM -0700, Florian Fainelli wrote:
>>>>> Completely crazy and outlandish idea, I know, but what's wrong with
>>>>> doing this in DSA?  
>>>>
>>>> I really do not have a problem with that approach however other stacked
>>>> devices like 802.1Q do not do that. It certainly scales a lot better to
>>>> do this within DSA rather than sprinkling DSA specific knowledge
>>>> throughout the network stack. Maybe for "configuration less" stacked
>>>> devices such as DSA, 802.1Q (bridge ports?), bond etc. it would be
>>>> acceptable to ensure that the lower device is always brought up?  
>>>
>>> For upper interfaces with more than one lower (bridge, bond) I'm not so
>>> sure. For uppers with a single lower (DSA, 8021q), it's pretty much a
>>> no-brainer to me. Question is, where to code this? I think it's ok to
>>> leave it in DSA, then 8021q could copy it as well if there was a need.
>>
>> FWIW no strong preference here. Maybe I'd lean slightly towards
>> Florian's approach since we can go to the always upping the CPU netdev
>> from that, if we start with auto-upping CPU netdev - user space may
>> depend on that in general so we can't go back.
>>
>> But up to you folks, this seems like a DSA-specific problem, vlans don't
>> get created before user space is up (AFAIK), so there is no compelling
>> reason to change them in my mind.
> 
> Right I remembered in my previous job we had a patch that would support
> creating VLAN devices when specified over ipconfig on the kernel command
> line, but that as never upstream AFAICT.
> 
>>
>> Florian for you patch specifially - can't we use
>> netdev_for_each_lower_dev()?
> 
> Looks like I forgot to respond here, yes we could do that because we do
> call netdev_upper_dev_link() in net/dsa/slave.c. Let me re-post with
> that done.

I remember now there was a reason for me to "open code" this, and this
is because since the patch is intended to be a bug fix, I wanted it to
be independent from: 2f1e8ea726e9 ("net: dsa: link interfaces with the
DSA master to get rid of lockdep warnings")

which we would be depending on and is only two-ish releases away. Let me
know if you prefer different fixes for different branches.
-- 
Florian

  reply	other threads:[~2020-11-16 23:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-19 17:17 [PATCH net] net: Have netpoll bring-up DSA management interface Florian Fainelli
2020-10-19 20:02 ` Vladimir Oltean
2020-10-19 21:03   ` Florian Fainelli
2020-10-19 21:19     ` Vladimir Oltean
2020-10-21  1:12       ` Jakub Kicinski
2020-11-16 23:06         ` Florian Fainelli
2020-11-16 23:20           ` Florian Fainelli [this message]
2020-11-16 23:37             ` Vladimir Oltean
2020-11-16 23:47             ` Jakub Kicinski
2020-11-16 23:54               ` Vladimir Oltean
2020-11-17  0:04                 ` Jakub Kicinski
2020-11-17  0:12                   ` Vladimir Oltean
2020-11-17  0:16                     ` Florian Fainelli
2020-11-17  0:53 ` Vladimir Oltean

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=d2dbb984-604a-ecbd-e717-2e9942fdbdaa@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=wangyunjian@huawei.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).