RE: [PATCH v2 net-next 0/3] net: sctp: Add partial MSG_MORE support to SCTP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: David Miller 
> From: David Laight <David.Laight@xxxxxxxxxx>
> Date: Wed, 9 Jul 2014 08:29:11 +0000
> 
> > If an application has disabled Nagle then it is almost impossible
> > to get more than one DATA chunk into an ethernet packet even if
> > the application has more than one data chunk ready to transmit.
> >
> > This could be fixed by adding an SCTP_CORK socket option - but
> > using that requires a lot of system calls.
> > An alternative is to honour MSG_MORE - using it to mean that
> > another chunk will be sent soon.
> > (There isn't much point using MSG_MORE to allow a chunk be extended,
> > sendv() can be used for fragmented data.)
> >
> > This is a partial implementation and takes a couple of shortcuts:
> > 1) We only worry about whether MSG_MORE was set on the last send.
> >    Data sent (by the application) with MSG_MORE unset will only be
> >    unsent for flow control reasons.
> >    So if the last send had MSG_MORE set, and an ack opens the window
> >    then the unsent data won't be sent immediately.
> >
> > 2) If the application doesn't do a send with MSG_MORE unset, then
> >    buffered data shouldn't be buffered forever.
> >    Rather than using a timer (as TCP does - which ought to be configurable
> >    on a per-socket basis) we use the same rules as Nagle and ensure
> >    that there is always some data outstanding.
> >    This does mean that the first data chunk on an idle connection
> >    is send in its own packet even if MSG_MORE is set.
> 
> I need some SCTP experts to review this series, thanks.

One thing that makes it easier, is that there is only one conditional
in the entire sctp stack that checks whether Nagle is enabled.

	David



--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Networking Development]     [Linux OMAP]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux