On Fri, Mar 24, 2017 at 12:42 AM, Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx> wrote: > 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. Makes sence, thanks for making this clear, will post a new fix. -- 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
