From: Marcelo Ricardo Leitner > Sent: 23 March 2017 16:42 ... > > > David, are we on the same page now? ;-) Probably... > > > 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. It is also worth remembering that this is all about whether the first chunk in an ethernet frame is a data chunk. If a frame is being sent for some other reason (eg ack or heartbeat) then it will collect queued data chunks. I've seen hearbeats collect data chunks, I've not checked that this doesn't happen for heartbeats that are probing IP addresses. David -- 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
