On Mon, Nov 17, 2025 at 10:38:52AM +0800, Yumei Huang wrote:
> On Fri, Nov 14, 2025 at 12:19 PM David Gibson
> <david@gibson.dropbear.id.au> wrote:
> >
> > On Fri, Nov 14, 2025 at 11:05:51AM +0800, Yumei Huang wrote:
> > > On Fri, Nov 14, 2025 at 8:47 AM David Gibson
> > > <david@gibson.dropbear.id.au> wrote:
[snip]
> > > > > > > @@ -2811,10 +2821,15 @@ void tcp_get_rto_params(struct ctx *c)
> > > > > > >   v = read_file_integer(SYN_LINEAR_TIMEOUTS, SYN_LINEAR_TIMEOUTS_DEFAULT);
> > > > > > >   c->tcp.syn_linear_timeouts = MIN(v, MAX_SYNCNT);
> > > > > > >
> > > > > > > + v = read_file_integer(RTO_MAX_MS, RTO_MAX_MS_DEFAULT);
> > > > > > > + c->tcp.rto_max = MIN(DIV_ROUND_CLOSEST(v, 1000), INT_MAX);
> > > > > >
> > > > > > Possibly we should verify this is => RTO_INIT.
> > > > >
> > > > > As a sanity check, maybe, but I don't see any harmful effect if it's
> > > > > < RTO_INIT, right? So I'm not sure if we should. No preference from my
> > > > > side really.
> > > >
> > > > Sorry, describing this as >= RTO_INIT was misleading.  What I'm
> > > > concerned about here is if the kernel value is set to 400ms, we'll
> > > > round it to... 0s.
> > > >
> > > > So, really what I'm concerned about is that we ensure this is > 0.
> > >
> > > That's a good point.
> >
> > Actually, thinking about it, I wonder if makes more sense to always
> > round up to 1s, rather than to the nearest 1s.
> 
> So it's to replace DIV_ROUND_CLOSEST with DIV_ROUND_UP, right?

Yes.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson