Re: [RFC PATCH net-next 0/3] sctp: add GSO support
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: 2016-01-29 01:18:36
Also in:
linux-sctp
On Fri, Jan 29, 2016 at 12:36:05AM +0100, Michael Tuexen wrote:
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 Leitnerquoted
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.26Seizing 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 thisNo. 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? Thanks, Marcelo
Best regards Michaelquoted
snippet: "Sending a message using sendmsg() is atomic unless explicit end of record (EOR) marking is enabled on the socket specified by sd (see Section 8.1.26)." Best regards, Marceloquoted
Best regards Michaelquoted
Given the current implementation you can get almost the required behaviour by turning nagle off and on repeatedly. I did wonder whether the queued data could actually be picked up be a Heartbeat chunk that is probing a different remote address (which would be bad news). David -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html