* SCTP MSG_MORE code
@ 2017-03-20 17:49 David Laight
2017-03-21 6:01 ` Xin Long
0 siblings, 1 reply; 3+ messages in thread
From: David Laight @ 2017-03-20 17:49 UTC (permalink / raw)
To: linux-sctp@vger.kernel.org, netdev@vger.kernel.org
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SCTP MSG_MORE code
2017-03-20 17:49 SCTP MSG_MORE code David Laight
@ 2017-03-21 6:01 ` Xin Long
2017-03-23 16:11 ` David Laight
0 siblings, 1 reply; 3+ messages in thread
From: Xin Long @ 2017-03-21 6:01 UTC (permalink / raw)
To: David Laight, Marcelo Ricardo Leitner, Neil Horman
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org
On Tue, Mar 21, 2017 at 1:49 AM, David Laight <David.Laight@aculab.com> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: SCTP MSG_MORE code
2017-03-21 6:01 ` Xin Long
@ 2017-03-23 16:11 ` David Laight
0 siblings, 0 replies; 3+ messages in thread
From: David Laight @ 2017-03-23 16:11 UTC (permalink / raw)
To: 'Xin Long', Marcelo Ricardo Leitner, Neil Horman
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org
From: Xin Long
> Sent: 21 March 2017 06:01
> On Tue, Mar 21, 2017 at 1:49 AM, David Laight <David.Laight@aculab.com> 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'.
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-23 16:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-20 17:49 SCTP MSG_MORE code David Laight
2017-03-21 6:01 ` Xin Long
2017-03-23 16:11 ` David Laight
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).