From: Jakub Sitnicki <jakub@cloudflare.com>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org, Jason Xing <kerneljasonxing@gmail.com>,
Adrien Vasseur <avasseur@cloudflare.com>,
Lee Valentine <lvalentine@cloudflare.com>,
kernel-team@cloudflare.com
Subject: Re: [PATCH net-next 1/2] tcp: Measure TIME-WAIT reuse delay with millisecond precision
Date: Wed, 04 Dec 2024 22:58:16 +0100 [thread overview]
Message-ID: <87ed2naz5z.fsf@cloudflare.com> (raw)
In-Reply-To: <CANn89iL5oE79_qtNUFFsyxLXoJALJCZgawsubuvn1XOcOuOzFw@mail.gmail.com> (Eric Dumazet's message of "Wed, 4 Dec 2024 20:22:36 +0100")
On Wed, Dec 04, 2024 at 08:22 PM +01, Eric Dumazet wrote:
> On Wed, Dec 4, 2024 at 7:53 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>
>> A low effort alternative would be to introduce a new field to hold a
>> millisecond timestamp for measuring the TW reuse delay. However, this would
>> cause the struct tcp_timewait_socket size to go over 256 bytes and overflow
>> into another cache line.
>
> s/tcp_timewait_socket/tcp_timewait_sock/
>
> Can you elaborate on this ?
>
> Due to SLUB management, note that timewait_sockets are not cache
> aligned, and use 264 bytes already:
>
> # grep tw_sock_TCP /proc/slabinfo
> tw_sock_TCPv6 3596 3596 264 62 4 : tunables 0 0
> 0 : slabdata 58 58 0
> tw_sock_TCP 0 0 264 62 4 : tunables 0 0
> 0 : slabdata 0 0 0
>
> In any case, there is one 4 byte hole in struct inet_timewait_sock
> after tw_priority
You're right. <facepalm> Thanks for keeping me honest here.
I must have checked pahole on the host (Ubuntu LTS kernel) instead of
inside the dev VM, which shows:
# grep tw_sock_TCP /proc/slabinfo
tw_sock_TCPv6 0 0 288 28 2 : tunables 0 0 0 : slabdata 0 0 0
tw_sock_TCP 0 0 288 28 2 : tunables 0 0 0 : slabdata 0 0 0
# pahole -C tcp_timewait_sock
struct tcp_timewait_sock {
struct inet_timewait_sock tw_sk; /* 0 256 */
/* --- cacheline 4 boundary (256 bytes) --- */
u32 tw_rcv_wnd; /* 256 4 */
u32 tw_ts_offset; /* 260 4 */
u32 tw_ts_recent; /* 264 4 */
u32 tw_last_oow_ack_time; /* 268 4 */
u32 tw_ts_recent_stamp; /* 272 4 */
u32 tw_tx_delay; /* 276 4 */
/* size: 280, cachelines: 5, members: 7 */
/* last cacheline: 24 bytes */
};
#
Let me pivot to the simplest approach then and make use of that 4-byte
hole in inet_timewait_sock. (Which I didn't consider either, so thank
you for the idea.) This would save me from having to touch the PAWS
code.
next prev parent reply other threads:[~2024-12-04 21:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-04 18:53 [PATCH net-next 0/2] Make TIME-WAIT reuse delay deterministic and configurable Jakub Sitnicki
2024-12-04 18:53 ` [PATCH net-next 1/2] tcp: Measure TIME-WAIT reuse delay with millisecond precision Jakub Sitnicki
2024-12-04 19:22 ` Eric Dumazet
2024-12-04 21:58 ` Jakub Sitnicki [this message]
2024-12-04 18:53 ` [PATCH net-next 2/2] tcp: Add sysctl to configure TIME-WAIT reuse delay Jakub Sitnicki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ed2naz5z.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=avasseur@cloudflare.com \
--cc=edumazet@google.com \
--cc=kernel-team@cloudflare.com \
--cc=kerneljasonxing@gmail.com \
--cc=lvalentine@cloudflare.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.