Re: Question about cca9bab1b72cd patch

On Wed, Dec 15, 2021 at 6:20 PM clementwei90@gmail.com
[off-list ref] wrote:

hello:
I have a question in patch cca9bab1b72cd ("tcp: use monotonic timestamps for PAWS").
In net/ipv4/tcp_ipv4.c file, before the patch, it was "get_seconds() - tcptw->tw_ts_recent_stamp > 1",
now it become "time_after32(ktime_get_seconds(), tcptw->tw_ts_recent_stamp)".
Before the patch, the judgment conditions is that the time difference must greater than 1,
means that the socket port reuse after 2 seconds. Now the conditions is became greater than 0,
meas it will reuse within 2 seconds. It make difference in tcp_tw_reuse option and it not explained in the patch description.
Why do it like this？Does it modify the original logic to make the socket port reuse faster?
What is the standard in tcp_tw_reuse?

If you really care [1], please provide RFC on which this logic is based on.

I say that new code is just fine, and would allow better reuse.

If precise sub-second timing was needed, I guess we would have used
jiffies based tstamp.

[1] By default, tw_reuse is only enabled on loopback.
Applications relying on it should really move on to something else in
our century.

Thank you.

---Original---
From: "clement wei"<redacted>
Date: Tue, Dec 14, 2021 09:13 AM
To: "Alexey Kuznetsov"<redacted>;
Cc: "Arnd Bergmann"<arnd@arndb.de>;"Eric Dumazet"<redacted>;"David Miller"<davem@davemloft.net>;
Subject: Re: Question about cca9bab1b72cd patch

Thank you. But I am confused that in > 1, means that the socket port
reuse after 2 seconds, now the > 0 meas it will reuse within 2
seconds.
What is the standard in tcp_tw_reuse?

Alexey Kuznetsov  于2021年12月13日周一 22:52写道：

quoted

On Mon, Dec 13, 2021 at 8:48 PM Arnd Bergmann  wrote:

quoted

FWIW, here is the original commit that introduced the '> 1':

https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/net/ipv4/tcp_ipv4.c?h=v2.5.8&id=b8439924316d5bcb266d165b93d632a4b4b859af

Sorry, I cannot tell after so long time. :-)

Most likely, > 1 was a mistake, probably coming from worries that > 0 does
not mean that some time has passed. But anyway logic of timestamps
does not require that any time actually passed, it is enough that new
timestamps are all later than ones sent before. So, time_after32() looks right.