[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7e21933-cd3b-43a2-9678-4f0e592ec87a@linux.dev>
Date: Fri, 14 Feb 2025 18:39:18 -0800
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: Stanislav Fomichev <stfomichev@...il.com>, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, dsahern@...nel.org,
ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, eddyz87@...il.com,
song@...nel.org, yonghong.song@...ux.dev, john.fastabend@...il.com,
kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org,
horms@...nel.org, ncardwell@...gle.com, kuniyu@...zon.com,
bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/3] bpf: add TCP_BPF_RTO_MAX for bpf_setsockopt
On 2/14/25 3:53 PM, Jason Xing wrote:
> Another related topic about rto min test, do you think it's necessary
> to add TCP_BPF_RTO_MIN into the setget_sockopt test?
hmm... not sure why it is related to the existing TCP_BPF_RTO_MIN.
I thought this patch is adding the new TCP_RTO_MAX_MS...
or you want to say, while adding a TCP_RTO_MAX_MS test, add a test for the
existing TCP_BPF_RTO_MIN also because it is missing in the setget_sockopt?
iirc, I added setget_sockopt.c to test a patch that reuses the kernel
do_*_{set,get}sockopt. Thus, it assumes the optname supports both set and get.
TCP_BPF_RTO_MIN does not support get, so I suspect setget_sockopt will not be a
good fit. They are unrelated, so I would leave it out of your patch for now.
Powered by blists - more mailing lists