[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iLz=U2RW8S+Yy1WpFYb+dyyPR8TwbMpUUEeUpV9X2hYoA@mail.gmail.com>
Date: Mon, 9 Dec 2024 11:20:42 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: "Dujeong.lee" <dujeong.lee@...sung.com>
Cc: Youngmin Nam <youngmin.nam@...sung.com>, Jakub Kicinski <kuba@...nel.org>,
Neal Cardwell <ncardwell@...gle.com>, davem@...emloft.net, dsahern@...nel.org,
pabeni@...hat.com, horms@...nel.org, guo88.liu@...sung.com,
yiwang.cai@...sung.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
joonki.min@...sung.com, hajun.sung@...sung.com, d7271.choe@...sung.com,
sw.ju@...sung.com, iamyunsu.kim@...sung.com, kw0619.kim@...sung.com,
hsl.lim@...sung.com, hanbum22.lee@...sung.com, chaemoo.lim@...sung.com,
seungjin1.yu@...sung.com
Subject: Re: [PATCH] tcp: check socket state before calling WARN_ON
On Mon, Dec 9, 2024 at 11:16 AM Dujeong.lee <dujeong.lee@...sung.com> wrote:
>
> Thanks for all the details on packetdrill and we are also exploring USENIX 2013 material.
> I have one question. The issue happens when DUT receives TCP ack with large delay from network, e.g., 28seconds since last Tx. Is packetdrill able to emulate this network delay (or congestion) in script level?
Yes, the packetdrill scripts can wait an arbitrary amount of time
between each event
+28 <next event>
28 seconds seems okay. If the issue was triggered after 4 days,
packetdrill would be impractical ;)
Powered by blists - more mailing lists