All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
	"Mahe Tardy" <mahe.tardy@gmail.com>
Cc: <bpf@vger.kernel.org>, <andrii@kernel.org>, <ast@kernel.org>,
	<daniel@iogearbox.net>, <davem@davemloft.net>,
	<willemb@google.com>, <eddyz87@gmail.com>, <edumazet@google.com>,
	<john.fastabend@gmail.com>, <kuba@kernel.org>, <horms@kernel.org>,
	<liamwisehart@meta.com>, <martin.lau@linux.dev>,
	<pabeni@redhat.com>, <song@kernel.org>, <netdev@vger.kernel.org>,
	<sdf.kernel@gmail.com>, <yonghong.song@linux.dev>,
	<jolsa@kernel.org>, <kuniyu@google.com>, <emil@etsalapatis.com>,
	<almagui@kernel.org>
Subject: Re: [PATCH bpf-next v2 1/3] bpf: add bpf_ksock_sendto() kfunc
Date: Wed, 21 Oct 2026 21:50:15 +0200	[thread overview]
Message-ID: <DMARZV0CMCU6.B7GRUVI8S0WT@gmail.com> (raw)
In-Reply-To: <CAEf4BzYA79tg5C+uzo3S5=MRgM_O7VMYtOwW59QMieJoFNOpVg@mail.gmail.com>

On Wed Oct 21, 2026 at 8:57 PM CEST, Andrii Nakryiko wrote:
> On Wed, Oct 21, 2026 at 11:39 AM Mahe Tardy <mahe.tardy@gmail.com> wrote:
>>
>> On Wed, Oct 21, 2026 at 10:56:23AM -0700, Andrii Nakryiko wrote:
>> > On Tue, Oct 20, 2026 at 8:59 AM Mahe Tardy <mahe.tardy@gmail.com> wrote:
>> > >
>> > > The motivation is to plumb more of the socket API into ksock, thus
>> > > supporting sendto() in addition to send() which makes a lot of sense in
>> > > the context of UDP sockets which are the only type currently supported.
>> > > This is useful when ksock is used to reply to specific addresses or send
>> > > to multiple addresses.
>> > >
>> > > Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
>> > > ---
>> > >  net/core/bpf_ksock.c | 96 +++++++++++++++++++++++++++++++-------------
>> > >  1 file changed, 69 insertions(+), 27 deletions(-)
>> > >
>>
>> [...]
>>
>> > >
>> > > -       return ret;
>> > > +/**
>> > > + * bpf_ksock_sendto() - Send data through a BPF kernel socket to a remote address.
>> > > + * @ks:                The BPF kernel socket context. Must be an acquired reference.
>> > > + * @data:      Pointer to the data to send.
>> > > + * @data__sz:  Size of the data to send.
>> > > + * @addr__nullable: Pointer to an IPv4 or IPv6 socket address, or NULL to use
>> > > + *                the connected destination.
>> > > + * @addr__sz:  Size of the address union, ignored when the address is NULL.
>> > > + *
>> > > + * Sends data to the specified address, or to the connected destination when
>> > > + * the address is NULL, best-effort and nonblocking. This may sleep
>> > > + * (kernel_sendmsg), so it can only be called from sleepable BPF programs.
>> > > + *
>> > > + * Return: Number of bytes sent on success, negative errno on error.
>> > > + */
>> > > +__bpf_kfunc int bpf_ksock_sendto(struct bpf_ksock *ks, const void *data, u32 data__sz,
>> >
>> > This would limit API to fixed-sized data only. Have you considered
>> > passing dynptr as a source of data, so you can send a wider variety of
>> > data? I don't have a strong opinion whether we should add a separate
>> > API or convert this one into dynptr, but I do think that having
>> > ability to work with variable-sized data is super useful and should be
>> > added early on.
>>
>> Oh wow this is really cool that you send this now. I was working this
>> afternoon on trying to see if a ksock sendmsg() would make sense, but
>> with these static buffer limitations as arguments, it actually didn't.
>> I'm not familiar with dynptr so I didn't think about it, but after a
>> quick check it looks like it would be a good match with the ksock API!
>>
>> As I understand, since bpf_ksock_send() is already part of 7.3, it's
>> best to not touch it, and having a simple send() available with a
>> fixed-size data might make sense.
>
> agreed
>
>>
>> But since bpf_ksock_sendto() was just merged, we could make it evolve to
>> use dynptr perhaps? How much time do we have for something which was
>> merged yesterday to be part of a release? Is it going to be send with
>> the 7.4 pull soon?
>>
>
> I'd send a follow up in the next few days, it can go in as a fix for
> kfunc in rc1 or something, unless others have differing opinions on
> this
>

Another option is to add dynptr variants of both, a pattern we have in other
APIs as well, so there would be no rush. We just have two more kfuncs:
bpf_ksock_send_dynptr() and bpf_ksock_sendto_dynptr().

>> >
>> > > +                                const union bpf_ksock_addr *addr__nullable,
>> > > +                                u32 addr__sz)
>> > > +{
>> > > +       return ksock_sendto(ks, data, data__sz, addr__nullable, addr__sz);
>> > >  }
>> > >
>> > >  __bpf_kfunc_end_defs();
>> > > @@ -255,6 +296,7 @@ BTF_KFUNCS_START(ksock_kfunc_btf_ids)
>> > >  BTF_ID_FLAGS(func, bpf_ksock_release, KF_RELEASE)
>> > >  BTF_ID_FLAGS(func, bpf_ksock_acquire, KF_ACQUIRE | KF_RCU | KF_RET_NULL)
>> > >  BTF_ID_FLAGS(func, bpf_ksock_send, KF_SLEEPABLE)
>> > > +BTF_ID_FLAGS(func, bpf_ksock_sendto, KF_SLEEPABLE)
>> > >  BTF_KFUNCS_END(ksock_kfunc_btf_ids)
>> > >
>> > >  #ifdef CONFIG_BPF_LSM
>> > > --
>> > > 2.43.0
>> > >



  reply	other threads:[~2026-10-21 19:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 15:58 [PATCH bpf-next v2 0/3] bpf: Add bpf_ksock_sendto() kfunc Mahe Tardy
2026-10-20 15:58 ` [PATCH bpf-next v2 1/3] bpf: add " Mahe Tardy
2026-10-21 17:56   ` Andrii Nakryiko
2026-10-21 18:39     ` Mahe Tardy
2026-10-21 18:57       ` Andrii Nakryiko
2026-10-21 19:50         ` Kumar Kartikeya Dwivedi [this message]
2026-10-20 15:58 ` [PATCH bpf-next v2 2/3] selftests/bpf: Test ksock sendto() Mahe Tardy
2026-10-20 15:58 ` [PATCH bpf-next v2 3/3] selftests/bpf: Test forbidden bpf_ksock_sendto() LSM attach Mahe Tardy
2026-10-20 21:00 ` [PATCH bpf-next v2 0/3] bpf: Add bpf_ksock_sendto() kfunc patchwork-bot+netdevbpf

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=DMARZV0CMCU6.B7GRUVI8S0WT@gmail.com \
    --to=memxor@gmail.com \
    --cc=almagui@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=emil@etsalapatis.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=liamwisehart@meta.com \
    --cc=mahe.tardy@gmail.com \
    --cc=martin.lau@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf.kernel@gmail.com \
    --cc=song@kernel.org \
    --cc=willemb@google.com \
    --cc=yonghong.song@linux.dev \
    /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.