SCTP MSG_MORE code

Something needs to be done with SCTP MSG_MORE before the end of the rc cycle.
The current code is definitely broken.

I objected to the last 'fix' patch because it clears the flag is a place where
I don't think it is necessary to do so - so could generate extra ethernet frames.

	David

On Tue, Mar 21, 2017 at 1:49 AM, David Laight [off-list ref] wrote:

Something needs to be done with SCTP MSG_MORE before the end of the rc cycle.
The current code is definitely broken.

agreed.

I objected to the last 'fix' patch because it clears the flag is a place where
I don't think it is necessary to do so - so could generate extra ethernet frames.

Sorry, can you double check the last 'fix' patch ?
I could not get 'generate extra ethernet frames'.

if we keep sending data with "MSG_MORE", after one ethernet frame
is sent, "followed by a second ethernet frame with 1 chunk in it" will NOT
happen, as in this loop the asoc's msg_more flag is still set, and this flush
is called by sctp_sendmsg(the function msg_more should care more).


If your point about "generate extra ethernet frames"  is right, sure, I will
change the way to fix that. but before this, pls check it again, appreciate it.

        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

From: Xin Long

Sent: 21 March 2017 06:01
On Tue, Mar 21, 2017 at 1:49 AM, David Laight [off-list ref] wrote:

quoted

Something needs to be done with SCTP MSG_MORE before the end of the rc cycle.
The current code is definitely broken.

agreed.

quoted

I objected to the last 'fix' patch because it clears the flag is a place where
I don't think it is necessary to do so - so could generate extra ethernet frames.

Sorry, can you double check the last 'fix' patch ?
I could not get 'generate extra ethernet frames'.

It would require the connection be 'flow controlled' and/or have
retransmissions.
Otherwise 'data chunk only' ethernet frames are only generated in response
to send() so would always see the value from the last send().

if we keep sending data with "MSG_MORE", after one ethernet frame
is sent, "followed by a second ethernet frame with 1 chunk in it" will NOT
happen, as in this loop the asoc's msg_more flag is still set, and this flush
is called by sctp_sendmsg(the function msg_more should care more).


If your point about "generate extra ethernet frames"  is right, sure, I will
change the way to fix that. but before this, pls check it again, appreciate it.

I won't be able to test this in the short term.

	David