netdev - [PATCH v2 net-next 0/3] net: sctp: Add partial MSG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Jul 2014 08:29:11 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	"'netdev@...r.kernel.org'" <netdev@...r.kernel.org>,
	"'linux-sctp@...r.kernel.org'" <linux-sctp@...r.kernel.org>
CC:	"'davem@...emloft.net'" <davem@...emloft.net>
Subject: [PATCH v2 net-next 0/3] net: sctp:  Add partial MSG_MORE support to
 SCTP

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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html