On Thu, Mar 23, 2017 at 12:35:46PM +0800, Xin Long wrote: > On Thu, Mar 23, 2017 at 1:33 AM, Marcelo Ricardo Leitner > <marcelo.leitner@xxxxxxxxx> wrote: > > On Wed, Mar 22, 2017 at 02:07:37PM +0000, David Laight wrote: > >> Regardless of the MSG_MORE flags associated with any specific send() > >> request there will always be protocol effects (like retransmissions > >> or flow control 'on') that will generate different 'chunking'. > > > > Yes, those are the ones that may lead to some confusion on how it > > actually works, and mangling them is not really desired for the > > sideeffects that it might have. > > > > Sooner or later we could have bug reports like "hey this chunk shouldn't > > have been packed with that." if we stick with the initial proposition, > > while with David's view, we are only promising to not send packets with > > a single chunk and as long as the application send more data fast enough. > > > > David, are we on the same page now? ;-) > > > > Xin, what do you think? > If we insist that MSG_MORE means not to send ANY data, I compromise. > does ANY include retransmission DATA? should MSG_MORE block > retransmission ? That's not really what he meant by that, I think. That "ANY" in there is a way to refer to the entire buf and not that msg sendmsg is sending. Later I explained what I got from his explanation, which should be more like: "If MSG_MORE was used, and there are no packets in flight, do not send a packet right away because the application is going to send more data." Would have to handle the (Not-)Nagle situation too: "If not using Nagle and using MSG_MORE, try to not generate a packet right away." (because this may send packets with a single chunk even if in_flight != 0) In both cases, if the flush is generated by other triggers, it's okay. Because if there are chunks already queued, they will be sent as soon as in_flight reaches 0 or some other break is lifted (flow control). Holding the chunk that was queued with MSG_MORE and sending a partial packet in this case because of MSG_MORE is not good, it's possibly not saving anything. Marcelo -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
