Pavel Begunkov wrote: > The network stack allows only one ubuf_info per skb, and unlike > MSG_ZEROCOPY, each io_uring zerocopy send will carry a separate > ubuf_info. That means that send requests can't reuse a previosly > allocated skb and need to get one more or more of new ones. That's fine > for large sends, but otherwise it would spam the stack with lots of skbs > carrying just a little data each. Can you give a little context why each send request has to be a separate ubuf_info? This patch series aims to make that model more efficient. Would it be possible to just change the model instead? I assume you tried that and it proved unworkable, but is it easy to explain what the fundamental blocker is? MSG_ZEROCOPY uses uarg->len to identify multiple consecutive send operations that can be notified at once.
