On 4/15/24 16:06, Willem de Bruijn wrote:
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?
Right, a small change I will add later. Without ops though
having 3 callback fields in uargs would be out of hands.
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(..);
Let me note that the patch doesn't change the number of indirect
calls but only adds one extra deref to get the callback, i.e.
uarg->ops->callback() instead of uarg->callback(). Your snippet
goes an extra mile and removes the indirect call.
Can I take it as that you're fine with the direction of the
patch? Or do you want me to change anything?
--
Pavel Begunkov
