On Fri, Jan 29, 2016 at 11:57:46AM +0100, Michael Tuexen wrote:

quoted

On 29 Jan 2016, at 02:18, Marcelo Ricardo Leitner [off-list ref] wrote:

On Fri, Jan 29, 2016 at 12:36:05AM +0100, Michael Tuexen wrote:

quoted

quoted

On 28 Jan 2016, at 22:03, Marcelo Ricardo Leitner [off-list ref] wrote:

On Thu, Jan 28, 2016 at 06:54:06PM +0100, Michael Tuexen wrote:

quoted

quoted

On 28 Jan 2016, at 14:51, David Laight [off-list ref] wrote:

From: Marcelo Ricardo Leitner

quoted

Sent: 27 January 2016 17:07
This patchset is merely a RFC for the moment. There are some
controversial points that I'd like to discuss before actually proposing
the patches.

You also need to look at how a 'user' can actually get SCTP to
merge data chunks in the first place.

With Nagle disabled (and it probably has to be since the data flow
is unlikely to be 'command-response' or 'unidirectional bulk')
it is currently almost impossible to get more than one chunk
into an ethernet frame.

Support for MSG_MORE would help.

What about adding support for the explicit EOR mode as specified in
https://tools.ietf.org/html/rfc6458#section-8.1.26

Seizing the moment to clarify my understanding on that. :)
Such multiple calls to send system calls will result in a single data
chunk. Is that so? That's what I get from that text and also from this

No. It results in a single user message. This means you can send
a user message larger than the send buffer size. How the user message
is fragmented in DATA chunks is transparent to the upper layer.

Does this make things clearer?

I think so, yes. So it allows delaying setting the Ending fragment bit
until the application set SCTP_EOR. All the rest before this stays as
before: first send() will generate a chunk with Beginning bit set and
may generate some other middle-fragments (no B nor E bit set) if
necessary, second to N-1 call to send will generate only middle
fragments, while the last send, with SCTP_EOF, will then set the Ending
fragment in the last one. Right?

Yes. But there are no restrictions on the user data provided in send()
calls and DATA chunks. So you can
send(100000 byte, no SCTP_EOR)
resulting in one DATA chunk with the B bit, several with no B and no E bit.
send(100000 byte, no SCTP_EOR)
resulting in several chunks with no B and no E bit.
send(100000 byte, SCTP_EOR)
resulting in several chunks with no B and no E bit and one (the last) chunk
with the E bit.

On the other hand you can do
send(1 byte, no SCTP_EOR)
resulting in a single DATA chunk with the E bit set.
send(1 byte, no SCTP_EOR)
send(1 byte, no SCTP_EOR)
send(1 byte, no SCTP_EOR)
send(1 byte, no SCTP_EOR)
send(1 byte, no SCTP_EOR)
All resulting in a single DATA chunk with 5 bytes user data and no B or E bit.
(For example if Nagle is enabled and only after the last send call the SACK arrives).
send(1 byte, SCTP_EOR)
results in a single DATA chunk with the E bist set.

Cool, thanks Michael. It will be quite fun to mix this with MSG_MORE
logic, I think :)

Best regards,
Marcelo