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
