On 24/07/2020 22:05, Stephen Hemminger wrote:
> On Fri, 24 Jul 2020 19:24:35 +0300
> niko...@cumulusnetworks.com wrote:
>
>> On 24 July 2020 19:15:17 EEST, Stephen Hemminger
>> <step...@networkplumber.org> wrote:
>>>
>>> The bridge portion of ip command was not scaling so the
>>> values were off.
>>>
>>> The netlink API's for setting and reading timers all conform
>>> to the kernel standard of scaling the values by USER_HZ (100).
>>>
>>> Fixes: 28d84b429e4e ("add bridge master device support")
>>> Fixes: 7f3d55922645 ("iplink: bridge: add support for
>>> IFLA_BR_MCAST_MEMBERSHIP_INTVL")
>>> Fixes: 10082a253fb2 ("iplink: bridge: add support for
>>> IFLA_BR_MCAST_LAST_MEMBER_INTVL")
>>> Fixes: 1f2244b851dd ("iplink: bridge: add support for
>>> IFLA_BR_MCAST_QUERIER_INTVL")
>>> Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
>>> ---
>>
>> While I agree this should have been done from the start, it's too late to
>> change.
>> We'll break everyone using these commands.
>> We have been discussing to add _ms version of all these which do the proper
>> scaling. I'd prefer that, it's least disruptive
>> to users.
>>
>> Every user of the old commands scales the values by now.
>
> So bridge is inconsistent with all other api's in iproute2!
> And the bridge option in ip link is scaled differently than the bridge-utils
> or sysfs.
>
Yeah, that is not new, it's been like that for years.
> Maybe an environment variable?
> Or add new fixed syntax option and don't show the old syntax?
>
Anything that doesn't disrupt normal processing sounds good.
So it must be opt-in, we can't just change the default overnight.
The _ms version of all values is that - new fixed syntax options for all
current options
and anyone who wants to use a "normal" time-based option would use those as
they'll be
automatically scaled.
