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. Because of the way Nagle is implemented in SCTP, the change is effectively just enabling and disabling Nagle prior to each send. The patch is split into 3 parts: Parts 1 and 2 do not affect the logic. 1) Splits out the 6-clause condition (all of which must be true) for Nagle to delay sends into 6 if statements. This allows each condition to have its own comment. 2) Renames an internal return value. 3) Renames the 'nodelay' field to 'tx_delay' and defines separate bits for 'Nagle' and MSG_MORE (an extra bit could be used for SCTP_CORKED). So 'tx_delay' contains the 'reason(s) why a transmit should be delayed'. Save the MSG_MORE bit from the last send in 'tx_delay', apply the same delay rules as if Nagle were enabled. Changes for v2: Parts 1 and 2 added, constants replaced by defines. 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
