Hi Stephen,
"man ip-link" mentions for ageing_time, forward_delay, hello_time and so
on, that they specify a number of seconds.
The bridge core takes the value from userspace unfiltered and passes it
through the clock_t_to_jiffies function. This begs the questions "what
is clock_t measured in"?
One would think it does this since patch "[BRIDGE]: Make use of
jiffies_to_clock." [1], but actually it appears to have done that even
before (this patch is only a non-functional API change).
Actually the clock_t_to_jiffies function (added in patch [2] with rather
minimal introduction) should arguably be called user_ticks_to_jiffies,
and there aren't a lot of users apart from the bridge driver.
I'm finding that in order for me to convert the value emitted by the
bridge driver into anything with physical significance, I have to
multiply the ageing_time with the cosmological constant of USER_HZ (100
per popular vote).
# ip link add name br0 type bridge stp_state 1 ageing_time 1
[ 2368.667020] br0: br_set_ageing_time: ageing_time (clock_t) 1 t
(jiffies) 1
[ 2368.673891] br0: __set_ageing_time: t (jiffies) 1 ageing_time (clock_t) 1
It is quite apparent that clock_t_to_jiffies doesn't convert from
seconds to jiffies. By the way I am quite puzzled as to how downstream
users of this function, such as dsa_port_ageing_time which further
convert using jiffies_to_msecs, have ever worked.
Am I missing something obvious?
Thanks,
-Vladimir
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=ef443d0f02bb66d8ed4976e459ddd11b8b1407b7
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=220443f8fa6562345e6848fa9f3c956343daf0d6
