Re: [RFC PATCH net-next 0/2] Configuring PFC stall prevention via ethtool

[Andrew Lunn <andrew@lunn.ch>]

On Thu, Nov 16, 2017 at 11:17:36AM +0200, Eran Ben Elisha wrote:
> On Thu, Nov 16, 2017 at 4:44 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> What do other vendors support? Time? Number of pause frames sent?
> >
> > So i checked a few Marvell Switches. You can also specify a time. It
> > is a little bit more complex than that, since the units of time depend
> > on the link speed. But converting a time in ms to what the register
> > wants is possible.
> >
> > So i'm thinking rather than a poorly defined 'Auto', passing a time
> > would be better.
> >
> >       Andrew
> Hi Andrew,
> 
> We were using the term 'Auto' for few reasons.
> 1. Not confusing the user with the question of what is the correct
> value (100 ms is good? Bad?)
> 2. Allowing exposure of new mechanism in the future without user need
> to change its commands
> 3. Letting the device to decide on best approach according to its
> capabilities, link speed, etc.
> 
> Our initial thought was to expose with timeout as you suggested, but
> it felt very restrictive due to the reasons I mentioned.

I just find 'auto' to be very unclearly defined. Auto-negotiation is
well defined, it is specified in 802.3. But what does Auto mean here?
Why 8ms? Why not 42ms? or 420ms? Auto also generally means some sort
of dynamic behaviour. Make changes depending on the current
conditions. Where as your implementation seems to be fixed at 8ms.

Does 802.3 say anything about this at all? Does it list the 8 seconds
your driver defaults to?

Thanks
	Andrew