netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).