From: Willem de Bruijn <[email protected]>
To: Pavel Begunkov <[email protected]>,
Willem de Bruijn <[email protected]>,
[email protected], [email protected]
Cc: Jens Axboe <[email protected]>,
"David S . Miller" <[email protected]>,
Jakub Kicinski <[email protected]>,
David Ahern <[email protected]>,
Eric Dumazet <[email protected]>
Subject: Re: [RFC 1/6] net: extend ubuf_info callback to ops structure
Date: Mon, 15 Apr 2024 11:06:52 -0400 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
Pavel Begunkov wrote:
> On 4/14/24 18:07, Willem de Bruijn wrote:
> > Pavel Begunkov wrote:
> >> We'll need to associate additional callbacks with ubuf_info, introduce
> >> a structure holding ubuf_info callbacks. Apart from a more smarter
> >> io_uring notification management introduced in next patches, it can be
> >> used to generalise msg_zerocopy_put_abort() and also store
> >> ->sg_from_iter, which is currently passed in struct msghdr.
> >
> > This adds an extra indirection for all other ubuf implementations.
> > Can that be avoided?
>
> It could be fitted directly into ubuf_info, but that doesn't feel
> right. It should be hot, so does it even matter?
That depends on the workload (working set size)?
> On the bright side,
> with the patch I'll also ->sg_from_iter from msghdr into it, so it
> doesn't have to be in the generic path.
I don't follow this: is this suggested future work?
>
> I think it's the right approach, but if you have a strong opinion
> I can fit it as a new field in ubuf_info.
If there is a significant cost, I suppose we could use
INDIRECT_CALL or go one step further and demultiplex
based on the new ops
if (uarg->ops == &msg_zerocopy_ubuf_ops)
msg_zerocopy_callback(..);
next prev parent reply other threads:[~2024-04-15 15:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 12:55 [RFC 0/6] implement io_uring notification (ubuf_info) stacking Pavel Begunkov
2024-04-12 12:55 ` [RFC 1/6] net: extend ubuf_info callback to ops structure Pavel Begunkov
2024-04-13 17:17 ` David Ahern
2024-04-14 17:07 ` Willem de Bruijn
2024-04-15 0:07 ` Pavel Begunkov
2024-04-15 15:06 ` Willem de Bruijn [this message]
2024-04-15 18:55 ` Pavel Begunkov
2024-04-15 19:01 ` Willem de Bruijn
2024-04-16 14:50 ` David Ahern
2024-04-16 15:31 ` Pavel Begunkov
2024-04-12 12:55 ` [RFC 2/6] net: add callback for setting a ubuf_info to skb Pavel Begunkov
2024-04-13 17:18 ` David Ahern
2024-04-12 12:55 ` [RFC 3/6] io_uring/notif: refactor io_tx_ubuf_complete() Pavel Begunkov
2024-04-12 12:55 ` [RFC 4/6] io_uring/notif: remove ctx var from io_notif_tw_complete Pavel Begunkov
2024-04-12 12:55 ` [RFC 5/6] io_uring/notif: simplify io_notif_flush() Pavel Begunkov
2024-04-12 12:55 ` [RFC 6/6] io_uring/notif: implement notification stacking Pavel Begunkov
2024-04-14 17:10 ` Willem de Bruijn
2024-04-14 23:55 ` Pavel Begunkov
2024-04-15 15:15 ` Willem de Bruijn
2024-04-15 18:51 ` Pavel Begunkov
2024-04-15 19:02 ` Willem de Bruijn
2024-04-12 13:44 ` [RFC 0/6] implement io_uring notification (ubuf_info) stacking Jens Axboe
2024-04-12 14:52 ` Jens Axboe
2024-04-13 17:17 ` David Ahern
2024-04-15 0:08 ` Pavel Begunkov
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=661d428c4c454_1073d2945f@willemb.c.googlers.com.notmuch \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox