All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Stefan Chulski <stefanc@marvell.com>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Jakub Kicinski <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Marcin Wojtas (mw@semihalf.com)" <mw@semihalf.com>,
	Nadav Haklai <nadavh@marvell.com>,
	Yan Markman <ymarkman@marvell.com>
Subject: Re: [EXT] Re: Phylink flow control support on ports with MLO_AN_FIXED auto negotiation
Date: Tue, 16 Feb 2021 14:08:16 +0100	[thread overview]
Message-ID: <YCvDwMiOL2H+nv7S@lunn.ch> (raw)
In-Reply-To: <CO6PR18MB3873A73FCB7DD1233249B314B0889@CO6PR18MB3873.namprd18.prod.outlook.com>

On Mon, Feb 15, 2021 at 08:33:19PM +0000, Stefan Chulski wrote:
> > > > > > I discussed it with Andrew earlier last year, and his response was:
> > > > > >
> > > > > >  DT configuration of pause for fixed link probably is
> > > > > > sufficient. I don't  remember it ever been really discussed for
> > > > > > DSA. It was a Melanox  discussion about limiting pause for the
> > > > > > CPU. So I think it is safe to  not implement ethtool -A, at
> > > > > > least until somebody has a real use case  for it.
> > > > > >
> > > > > > So I chose not to support it - no point supporting features that
> > > > > > people aren't using. If you have a "real use case" then it can be added.
> > > > >
> > > > > This patch may be sufficient - I haven't fully considered all the
> > > > > implications of changing this though.
> > > >
> > > > Did you try this patch? What's the outcome?
> > >
> > > For me patch worked as expected.
> > 
> > Hi Stefan
> > 
> > Russell's patch allows it, but i would be interested in knows why you actually
> > need it. What is your use case for changing this on the fly?
> > 
> > 	 Andrew
> 
> Usually, user prefer have the capability disable/enable flow control on the fly.
> For example:
> Armada connected by 10G fixed link to SOHO switch and SOHO has 10 external 1G LAN interfaces.
> When we have 2 flows (from Armada to LAN) from two different ports, we have an obvious congestion issue.
> Bursts on 10G interface would cause FC frames on Armada<->SOHO 10G port and one flow would affect another.
> In some use cases, the user would prefer lossless traffic and keep FC, for another use case (probably UDP streaming) disable FC.

O.K, so you have reasonable uses cases for it. I'm O.K. with this.

     Andrew

      reply	other threads:[~2021-02-16 13:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-31 10:12 Phylink flow control support on ports with MLO_AN_FIXED auto negotiation Stefan Chulski
     [not found] ` <20210131103549.GA1463@shell.armlinux.org.uk>
2021-01-31 10:51   ` [EXT] " Stefan Chulski
     [not found]     ` <20210131111214.GB1463@shell.armlinux.org.uk>
2021-01-31 12:19       ` Russell King - ARM Linux admin
2021-02-13 11:39         ` Russell King - ARM Linux admin
2021-02-14  9:33           ` Stefan Chulski
2021-02-15 16:19           ` Stefan Chulski
2021-02-15 16:24             ` Russell King - ARM Linux admin
2021-02-15 18:18             ` Andrew Lunn
2021-02-15 20:33               ` Stefan Chulski
2021-02-16 13:08                 ` Andrew Lunn [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=YCvDwMiOL2H+nv7S@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mw@semihalf.com \
    --cc=nadavh@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=stefanc@marvell.com \
    --cc=ymarkman@marvell.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.