lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250704092628.80593-1-yangfeng59949@163.com>
Date: Fri,  4 Jul 2025 17:26:28 +0800
From: Feng Yang <yangfeng59949@....com>
To: david.laight.linux@...il.com
Cc: aleksander.lobakin@...el.com,
	almasrymina@...gle.com,
	asml.silence@...il.com,
	davem@...emloft.net,
	ebiggers@...gle.com,
	edumazet@...gle.com,
	horms@...nel.org,
	kerneljasonxing@...il.com,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	stfomichev@...il.com,
	willemb@...gle.com,
	yangfeng59949@....com,
	yangfeng@...inos.cn
Subject: Re: [PATCH v3] skbuff: Add MSG_MORE flag to optimize large packet transmission

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

> On Thu, 3 Jul 2025 10:48:40 +0200
> Paolo Abeni <pabeni@...hat.com> wrote:
> 
> > On 6/30/25 9:10 AM, Feng Yang wrote:
> > > From: Feng Yang <yangfeng@...inos.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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ