All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: David Miller <davem@davemloft.net>
Cc: thomas.petazzoni@bootlin.com, kuba@kernel.org,
	linux@armlinux.org.uk, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-nex 2/2] net: mvneta: Don't speed down the PHY when changing mtu
Date: Wed, 29 Jul 2020 17:53:12 +0800	[thread overview]
Message-ID: <20200729175312.6d6370cf@xhacker.debian> (raw)
In-Reply-To: <20200728.175202.598794850221205861.davem@davemloft.net>

Hi David,

On Tue, 28 Jul 2020 17:52:02 -0700 (PDT) David Miller wrote:

> 
> 
> > @@ -3651,7 +3651,8 @@ static void mvneta_stop_dev(struct mvneta_port *pp)
> >
> >       set_bit(__MVNETA_DOWN, &pp->state);
> >
> > -     if (device_may_wakeup(&pp->dev->dev))
> > +     if (device_may_wakeup(&pp->dev->dev) &&
> > +         pp->pkt_size == MVNETA_RX_PKT_SIZE(pp->dev->mtu))
> >               phylink_speed_down(pp->phylink, false);
> >  
> 
> This is too much for me.
> 
> You shouldn't have to shut down the entire device and take it back up
> again just to change the MTU.
> 
> Unfortunately, this is a common pattern in many drivers and it is very
> dangerous to take this lazy path of just doing "stop/start" around
> the MTU change.
> 
> It means you can't recover from partial failures properly,
> f.e. recovering from an inability to allocate queue resources for the
> new MTU.
> 
> To solve this properly, you must restructure the MTU change such that
> is specifically stops the necessary and only the units of the chip
> necessary to change the MTU.
> 
> It should next try to allocate the necessary resources to satisfy the
> MTU change, keeping the existing resources allocated in case of
> failure.
> 
> Then, only is all resources are successfully allocated, it should
> commit the MTU change fully and without errors.
> 
> Then none of these link flapping issues are even possible.

Thanks a lot for pointing out the correct direction. Refactoring change
mtu method needs more time(maybe for linux-5.10 is reasonable), so I
just drop patch2 in v2.

      reply	other threads:[~2020-07-29  9:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 11:50 [PATCH net-nex 0/2] net: mvneta: improve phylink_speed_up/down usage Jisheng Zhang
2020-07-27 11:51 ` [PATCH net-nex 1/2] net: mvneta: fix comment about phylink_speed_down Jisheng Zhang
2020-07-27 11:53 ` [PATCH net-nex 2/2] net: mvneta: Don't speed down the PHY when changing mtu Jisheng Zhang
2020-07-29  0:52   ` David Miller
2020-07-29  9:53     ` Jisheng Zhang [this message]

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=20200729175312.6d6370cf@xhacker.debian \
    --to=jisheng.zhang@synaptics.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=thomas.petazzoni@bootlin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.