On 08/01/2017 03:00 PM, Timur Tabi wrote: > On 08/01/2017 04:51 PM, Florian Fainelli wrote: > >> A few adapters (bcmgenet, bcmsysport) support configuring the pause >> quanta so it would not be inconceivable to try to update >> ethtool_pauseparam to include additional fields such as: > > Wouldn't this require a change to the user space tool?
It would yes. > >> - number of pause frames to send where we define an arbitrary high >> default value (e.g: 0xffff), N < 0xffff is something drivers can test >> for whether they support it, and 0 is only valid if pause is already >> disabled >> >> - pause quanta (16-bits) >> >> Private flags are not usually that great and there could be more >> adapters capable of doing the same pause frame number configuration, but >> since there is no available knob it's hard to know. > > Well, for the EMAC, the quanta in this case would be either 1 or > infinite. For other devices, it could be any combination of values. In > a future revision of the hardware, we might support a variable quanta. > And I suspect that some devices measure the quanta in time, not count. OK, either way is fine and there should be ways to convert back and forth without too much trouble. > > How would the user know what the acceptable values are? If I set the > quanta to 10 via user space, and my driver truncates that to 1, I don't > think that would be acceptable. There can be several ways to deal with that, we can either ask for a strict rejection before committing the changes to the HW, or we can have the HW round up/down to the nearest supported values and an user would call get_pauseparam() to see which value ended-up being used. Anyway food for thought, David decides what gets merged ;) -- Florian
