mbox series

[bpf-next,v3,0/2] bpf: support setting max RTO for bpf_setsockopt

Message ID 20250219081333.56378-1-kerneljasonxing@gmail.com (mailing list archive)
Headers show
Series bpf: support setting max RTO for bpf_setsockopt | expand

Message

Jason Xing Feb. 19, 2025, 8:13 a.m. UTC 
Support max RTO set by BPF program calling bpf_setsockopt().
Add corresponding selftests.

Jason Xing (2):
  bpf: support TCP_RTO_MAX_MS for bpf_setsockopt
  selftests/bpf: add rto max for bpf_setsockopt test

 net/core/filter.c                                   | 1 +
 tools/testing/selftests/bpf/progs/bpf_tracing_net.h | 1 +
 tools/testing/selftests/bpf/progs/setget_sockopt.c  | 1 +
 3 files changed, 3 insertions(+)

Comments

Daniel Xu Feb. 19, 2025, 4:33 p.m. UTC | #1 
Hi Jason,

On 2/19/25 12:44 AM, Jason Xing wrote:
> On Wed, Feb 19, 2025 at 4:27 PM <bot+bpf-ci@kernel.org> wrote:
>> Dear patch submitter,
>>
>> CI has tested the following submission:
>> Status:     FAILURE
>> Name:       [bpf-next,v3,0/2] bpf: support setting max RTO for bpf_setsockopt
>> Patchwork:  https://patchwork.kernel.org/project/netdevbpf/list/?series=935463&state=*
>> Matrix:     https://github.com/kernel-patches/bpf/actions/runs/13408235954
>>
>> Failed jobs:
>> build-aarch64-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452248960
>> build-s390x-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452248633
>> build-x86_64-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452249287
>> build-x86_64-llvm-17: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452250339
>> build-x86_64-llvm-17-O2: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452250688
>> build-x86_64-llvm-18: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452251018
>> build-x86_64-llvm-18-O2: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452251311
>>
>>
>> Please note: this email is coming from an unmonitored mailbox. If you have
>> questions or feedback, please reach out to the Meta Kernel CI team at
>> kernel-ci@meta.com.
> I think the only diff I made is that I removed the change in
> tools/include/uapi/linux/bpf.h from V2.
> diff --git a/tools/include/uapi/linux/tcp.h b/tools/include/uapi/linux/tcp.h
> index 13ceeb395eb8..7989e3f34a58 100644
> --- a/tools/include/uapi/linux/tcp.h
> +++ b/tools/include/uapi/linux/tcp.h
> @@ -128,6 +128,7 @@ enum {
>   #define TCP_CM_INQ             TCP_INQ
>
>   #define TCP_TX_DELAY           37      /* delay outgoing packets by XX usec */
> +#define TCP_RTO_MAX_MS         44      /* max rto time in ms */
>
> Last time everything was fine. I doubt it has something to do with the
> failure :S
>
> But I tested it locally and could not reproduce it. Could it be caused
> because of applying to a wrong branch? I'm afraid not, right?

It looks like TCP_RTO_MAX_MS is defined in include/uapi/linux/tcp.h. But

I don't see a uapi include in net/core/filter.c where you're using the 
definition.


Given the transitive dependency, perhaps some other file shifted? Seems 
better

to directly include the uapi header if you're going to use it.


Thanks,

Daniel
patchwork-bot+netdevbpf@kernel.org Feb. 19, 2025, 9:11 p.m. UTC | #2 
Hello:

This series was applied to bpf/bpf-next.git (net)
by Martin KaFai Lau <martin.lau@kernel.org>:

On Wed, 19 Feb 2025 16:13:30 +0800 you wrote:
> Support max RTO set by BPF program calling bpf_setsockopt().
> Add corresponding selftests.
> 
> Jason Xing (2):
>   bpf: support TCP_RTO_MAX_MS for bpf_setsockopt
>   selftests/bpf: add rto max for bpf_setsockopt test
> 
> [...]

Here is the summary with links:
  - [bpf-next,v3,1/2] bpf: support TCP_RTO_MAX_MS for bpf_setsockopt
    https://git.kernel.org/bpf/bpf-next/c/6810c771d316
  - [bpf-next,v3,2/2] selftests/bpf: add rto max for bpf_setsockopt test
    https://git.kernel.org/bpf/bpf-next/c/7a93ba804847

You are awesome, thank you!
Martin KaFai Lau Feb. 19, 2025, 9:12 p.m. UTC | #3 
On 2/19/25 8:33 AM, Daniel Xu wrote:
> Hi Jason,
> 
> On 2/19/25 12:44 AM, Jason Xing wrote:
>> On Wed, Feb 19, 2025 at 4:27 PM <bot+bpf-ci@kernel.org> wrote:
>>> Dear patch submitter,
>>>
>>> CI has tested the following submission:
>>> Status:     FAILURE
>>> Name:       [bpf-next,v3,0/2] bpf: support setting max RTO for bpf_setsockopt
>>> Patchwork:  https://patchwork.kernel.org/project/netdevbpf/list/?series=935463&state=*
>>> Matrix:     https://github.com/kernel-patches/bpf/actions/runs/13408235954
>>>
>>> Failed jobs:
>>> build-aarch64-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452248960
>>> build-s390x-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452248633
>>> build-x86_64-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452249287
>>> build-x86_64-llvm-17: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452250339
>>> build-x86_64-llvm-17-O2: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452250688
>>> build-x86_64-llvm-18: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452251018
>>> build-x86_64-llvm-18-O2: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452251311
>>>
>>>
>>> Please note: this email is coming from an unmonitored mailbox. If you have
>>> questions or feedback, please reach out to the Meta Kernel CI team at
>>> kernel-ci@meta.com.
>> I think the only diff I made is that I removed the change in
>> tools/include/uapi/linux/bpf.h from V2.
>> diff --git a/tools/include/uapi/linux/tcp.h b/tools/include/uapi/linux/tcp.h
>> index 13ceeb395eb8..7989e3f34a58 100644
>> --- a/tools/include/uapi/linux/tcp.h
>> +++ b/tools/include/uapi/linux/tcp.h
>> @@ -128,6 +128,7 @@ enum {
>>    #define TCP_CM_INQ             TCP_INQ
>>
>>    #define TCP_TX_DELAY           37      /* delay outgoing packets by XX usec */
>> +#define TCP_RTO_MAX_MS         44      /* max rto time in ms */
>>
>> Last time everything was fine. I doubt it has something to do with the
>> failure :S

kernel should not need tools/include, so no.

>>
>> But I tested it locally and could not reproduce it. Could it be caused
>> because of applying to a wrong branch? I'm afraid not, right?

Right, in v2, the patch 1 cannot be applied to bpf-next/master, so the bpf CI 
retried with bpf-next/net. It is the current bpf CI setup.

That v2's patch 1 is removed in v3, so the v3 applied cleanly to bpf-next/master 
and the bpf CI moved forward to test it.

I tested locally and I have applied v3 to bpf-next/net. Thanks.

May be the bpf CI can retry with bpf-next/net also there is kernel compilation 
error.
Jason Xing Feb. 19, 2025, 11:33 p.m. UTC | #4 
On Thu, Feb 20, 2025 at 5:12 AM Martin KaFai Lau <martin.lau@linux.dev> wrote:
>
> On 2/19/25 8:33 AM, Daniel Xu wrote:
> > Hi Jason,
> >
> > On 2/19/25 12:44 AM, Jason Xing wrote:
> >> On Wed, Feb 19, 2025 at 4:27 PM <bot+bpf-ci@kernel.org> wrote:
> >>> Dear patch submitter,
> >>>
> >>> CI has tested the following submission:
> >>> Status:     FAILURE
> >>> Name:       [bpf-next,v3,0/2] bpf: support setting max RTO for bpf_setsockopt
> >>> Patchwork:  https://patchwork.kernel.org/project/netdevbpf/list/?series=935463&state=*
> >>> Matrix:     https://github.com/kernel-patches/bpf/actions/runs/13408235954
> >>>
> >>> Failed jobs:
> >>> build-aarch64-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452248960
> >>> build-s390x-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452248633
> >>> build-x86_64-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452249287
> >>> build-x86_64-llvm-17: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452250339
> >>> build-x86_64-llvm-17-O2: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452250688
> >>> build-x86_64-llvm-18: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452251018
> >>> build-x86_64-llvm-18-O2: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452251311
> >>>
> >>>
> >>> Please note: this email is coming from an unmonitored mailbox. If you have
> >>> questions or feedback, please reach out to the Meta Kernel CI team at
> >>> kernel-ci@meta.com.
> >> I think the only diff I made is that I removed the change in
> >> tools/include/uapi/linux/bpf.h from V2.
> >> diff --git a/tools/include/uapi/linux/tcp.h b/tools/include/uapi/linux/tcp.h
> >> index 13ceeb395eb8..7989e3f34a58 100644
> >> --- a/tools/include/uapi/linux/tcp.h
> >> +++ b/tools/include/uapi/linux/tcp.h
> >> @@ -128,6 +128,7 @@ enum {
> >>    #define TCP_CM_INQ             TCP_INQ
> >>
> >>    #define TCP_TX_DELAY           37      /* delay outgoing packets by XX usec */
> >> +#define TCP_RTO_MAX_MS         44      /* max rto time in ms */
> >>
> >> Last time everything was fine. I doubt it has something to do with the
> >> failure :S
>
> kernel should not need tools/include, so no.
>
> >>
> >> But I tested it locally and could not reproduce it. Could it be caused
> >> because of applying to a wrong branch? I'm afraid not, right?
>
> Right, in v2, the patch 1 cannot be applied to bpf-next/master, so the bpf CI
> retried with bpf-next/net. It is the current bpf CI setup.
>
> That v2's patch 1 is removed in v3, so the v3 applied cleanly to bpf-next/master
> and the bpf CI moved forward to test it.
>
> I tested locally and I have applied v3 to bpf-next/net. Thanks.
>
> May be the bpf CI can retry with bpf-next/net also there is kernel compilation
> error.

Oh, I got it, thanks!