Re: SCTP data chunk bundling when SCTP_NODELAY is set

[Vlad Yasevich <vyasevich@gmail.com>]

On 06/17/2014 10:17 AM, David Laight wrote:
> If SCTP_NODELAY is set it is difficult to get SCTP to bundle
> data chunks into ethernet packets.
> This leads to very high packet rates which bundling could easily
> reduce by a factor or 8 or 10.
> 
> Nagle can't really be enabled because it generates unwanted delays
> when traffic is light (Nagle only really works for unidirectional bulk
> data and command-response when the messages are smaller than the mtu).
> 
> Even if the sending application knows it has more data to send,
> there isn't much it can do to get the chunks bundled.
> 
> AFAICT 'corking' the socket even stops full sized packets being
> sent - so the application will deadlock if the socket write
> buffer size is reached before the socket is 'uncorked'.
> This also means that the application can't send back to back
> full sized packets unless it uncorks the socket at exactly
> the right places.
> 
> MSG_MORE isn't supported by SCTP, but I'm not sure it would help.
> You really need a MSG_NO_MORE flag and to leave Nagle enabled.
> 
> About the only thing I can think of is to normally have Nagle
> enabled, and then perform the following sequence to force the
> buffered data chunks be sent:
> 1) disable Nagle
> 2) cork the socket
> 3) uncork the socket
> 4) enable Nagle
> Four socket calls is a little excessive!

First, how are you corking an SCTP socket?  There is no SCTP_CORK
and looking at the code, I don't see how an SCTP queue can be
cored by user...

I suppose we could implement SCTP_CORK to do the right thing.

I thought is possibly utilizing something like sendmmsg() and passing
an extra flag to let it be know that this is a multi-message send
that should be queued up by sctp..

-vlad

> 
> Any other ideas ?
> 
> 	David
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>