[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250705081640.232efec3@pumpkin>
Date: Sat, 5 Jul 2025 08:16:40 +0100
From: David Laight <david.laight.linux@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Feng Yang <yangfeng59949@....com>, 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, stfomichev@...il.com, willemb@...gle.com,
yangfeng@...inos.cn
Subject: Re: [PATCH v3] skbuff: Add MSG_MORE flag to optimize large packet
transmission
On Fri, 4 Jul 2025 17:50:42 +0200
Paolo Abeni <pabeni@...hat.com> wrote:
> On 7/4/25 11:26 AM, Feng Yang wrote:
> > 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?
>
> Without MSG_MORE N sendmsg() calls will emit on the wire N (small) packets.
>
> With MSG_MORE on the first N-1 calls, the stack will emit a single
> packet with larger size.
>
> UDP application may relay on packet size for protocol semantic. i.e. the
> application level message size could be expected to be equal to the
> (wire) packet size itself.
Correct, but the function is __skb_send_sock() - so you'd expect it to
send the 'message' held in the skb to the socket.
I don't think that the fact that the skb has fragments should make any
difference to what is sent.
In other words it ought to be valid for any code to 'linearize' the skb.
David
>
> Unexpectedly aggregating the packets may break the application. Also it
> can lead to IP fragmentation, which in turn could kill performances.
>
> > If that's not feasible, would the v2 version of the code work for UDP?
>
> My ask is to explicitly avoid MSG_MORE when the transport is UDP.
>
> /P
>
Powered by blists - more mailing lists