Re: [PATCH v3] skbuff: Add MSG_MORE flag to optimize large packet transmission

[Feng Yang <yangfeng59949@163.com>]

Thu, 3 Jul 2025 12:44:53 +0100 david.laight.linux@gmail.com wrote:

> On Thu, 3 Jul 2025 10:48:40 +0200
> Paolo Abeni <pabeni@redhat.com> wrote:
> 
> > On 6/30/25 9:10 AM, Feng Yang wrote:
> > > From: Feng Yang <yangfeng@kylinos.cn>
> > > 
> > > The "MSG_MORE" flag is added to improve the transmission performance of large packets.
> > > The improvement is more significant for TCP, while there is a slight enhancement for UDP.  
> > 
> > I'm sorry for the conflicting input, but i fear we can't do this for
> > UDP: unconditionally changing the wire packet layout may break the
> > application, and or at very least incur in unexpected fragmentation issues.
> 
> Does the code currently work for UDP?
> 
> I'd have thought the skb being sent was an entire datagram.
> But each semdmsg() is going to send a separate datagram.
> IIRC for UDP MSG_MORE indicates that the next send() will be
> part of the same datagram - so the actual send can't be done
> until the final fragment (without MSG_MORE) is sent.

If we add MSG_MORE, won't the entire skb be sent out all at once? Why doesn't this work for UDP?
If that's not feasible, would the v2 version of the code work for UDP?
Thanks.

> None of the versions is right for SCTP.
__skb_send_sock
	......
	INDIRECT_CALL_2(sendmsg, sendmsg_locked, sendmsg_unlocked, sk, &msg);
	......
This sending code doesn't seem to call sctp_sendmsg.

> The skb being sent needs to be processed as a single entity.
> Here MSG_MORE tells the stack that more messages follow and can be put
> into a single ethernet frame - but they are separate protocol messages.
> 
> OTOH I've not looked at where this code is called from.
> In particular, when it would be called with non-linear skb.
> 
> 	David