From: Vlad Yasevich > On 07/14/2014 12:27 PM, David Laight wrote: > > From: Vlad Yasevich > > ... > >>> + /* Setting MSG_MORE currently has the same effect as enabling Nagle. > >>> + * This means that the user can't force bundling of the first two data > >>> + * chunks. It does mean that all the data chunks will be sent > >>> + * without an extra timer. > >>> + * It is enough to save the last value since any data sent with > >>> + * MSG_MORE clear will already have been sent (subject to flow control). > >>> + */ > >>> + if (msg->msg_flags & MSG_MORE) > >>> + sp->tx_delay |= SCTP_F_TX_MSG_MORE; > >>> + else > >>> + sp->tx_delay &= ~SCTP_F_TX_MSG_MORE; > >>> + > >> > >> This is ok for 1-1 sockets, but it doesn't really work for 1-many sockets. If one of > >> the associations uses MSG_MORE while another does not, we'll see some interesting > >> side-effects on the wire. > > ... > > I don't think this is a problem. > > Not, it is not a _problem_, but it does make MSG_MORE rather useless > in some situations. Waiting for an ACK across low-latency links > is rare, but in a high-latency scenarios where you want to utilize the > bandwidth better with bundling, you may not see the gains you expect. > > Since MSG_MORE is association, it should be handled as such and an > a change on one association should not effect the others. I think the comments already say that it is only a partial implementation. (If you send 2 chunks on an idle connection, they get sent separately.) Perhaps I'll add a note about possibly 'odd' effects for 1-many sockets with multi-threaded apps. It helps a lot for my M3UA traffic. I can get the same effect on an old kernel by repeatedly changing SCTP_NODELAY, but that does rather rely on the way Nagle is implemented. 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
