Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 04 Aug 2020 15:58:31 -0700 (PDT)
Message-Id: <20200804.155831.644663742975051162.davem@davemloft.net>
To:     wenyang@linux.alibaba.com
Cc:     kuba@kernel.org, xlpang@linux.alibaba.com,
        caspar@linux.alibaba.com, andrew@lunn.ch, edumazet@google.com,
        jiri@mellanox.com, leon@kernel.org, jwi@linux.ibm.com,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: core: explicitly call linkwatch_fire_event to
 speed up the startup of network services
From:   David Miller <davem@davemloft.net>
In-Reply-To: <20200801085845.20153-1-wenyang@linux.alibaba.com>
References: <20200801085845.20153-1-wenyang@linux.alibaba.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Wen Yang <wenyang@linux.alibaba.com>
Date: Sat,  1 Aug 2020 16:58:45 +0800

> diff --git a/net/core/link_watch.c b/net/core/link_watch.c
> index 75431ca..6b9d44b 100644
> --- a/net/core/link_watch.c
> +++ b/net/core/link_watch.c
> @@ -98,6 +98,9 @@ static bool linkwatch_urgent_event(struct net_device *dev)
>  	if (netif_is_lag_port(dev) || netif_is_lag_master(dev))
>  		return true;
>  
> +	if ((dev->flags & IFF_UP) && dev->operstate == IF_OPER_DOWN)
> +		return true;
> +
>  	return netif_carrier_ok(dev) &&	qdisc_tx_changing(dev);
>  }
>  

You're bypassing explicitly the logic here:

	/*
	 * Limit the number of linkwatch events to one
	 * per second so that a runaway driver does not
	 * cause a storm of messages on the netlink
	 * socket.  This limit does not apply to up events
	 * while the device qdisc is down.
	 */
	if (!urgent_only)
		linkwatch_nextevent = jiffies + HZ;
	/* Limit wrap-around effect on delay. */
	else if (time_after(linkwatch_nextevent, jiffies + HZ))
		linkwatch_nextevent = jiffies;

Something about this isn't right.  We need to analyze what you are seeing,
what device you are using, and what systemd is doing to figure out what
the right place for the fix.

Thank you.