<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/sctp/outqueue.c, branch linux-4.8.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.8.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.8.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2016-09-30T06:07:05Z</updated>
<entry>
<title>sctp: change to check peer prsctp_capable when using prsctp polices</title>
<updated>2016-09-30T06:07:05Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2016-09-28T18:37:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=be4947bf46cb0e7a7d089e03c61bab35f1e695ce'/>
<id>urn:sha1:be4947bf46cb0e7a7d089e03c61bab35f1e695ce</id>
<content type='text'>
Now before using prsctp polices, sctp uses asoc-&gt;prsctp_enable to
check if prsctp is enabled. However asoc-&gt;prsctp_enable is set only
means local host support prsctp, sctp should not abandon packet if
peer host doesn't enable prsctp.

So this patch is to use asoc-&gt;peer.prsctp_capable to check if prsctp
is enabled on both side, instead of asoc-&gt;prsctp_enable, as asoc's
peer.prsctp_capable is set only when local and peer both enable prsctp.

Fixes: a6c2f792873a ("sctp: implement prsctp TTL policy")
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: remove prsctp_param from sctp_chunk</title>
<updated>2016-09-30T06:07:05Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2016-09-28T18:37:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0605483f6ace1f6b63e397c819a115ddcd13af0d'/>
<id>urn:sha1:0605483f6ace1f6b63e397c819a115ddcd13af0d</id>
<content type='text'>
Now sctp uses chunk-&gt;prsctp_param to save the prsctp param for all the
prsctp polices, we didn't need to introduce prsctp_param to sctp_chunk.
We can just use chunk-&gt;sinfo.sinfo_timetolive for RTX and BUF polices,
and reuse msg-&gt;expires_at for TTL policy, as the prsctp polices and old
expires policy are mutual exclusive.

This patch is to remove prsctp_param from sctp_chunk, and reuse msg's
expires_at for TTL and chunk's sinfo.sinfo_timetolive for RTX and BUF
polices.

Note that sctp can't use chunk's sinfo.sinfo_timetolive for TTL policy,
as it needs a u64 variables to save the expires_at time.

This one also fixes the "netperf-Throughput_Mbps -37.2% regression"
issue.

Fixes: a6c2f792873a ("sctp: implement prsctp TTL policy")
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: implement prsctp PRIO policy</title>
<updated>2016-07-11T20:25:39Z</updated>
<author>
<name>Xin Long</name>
</author>
<published>2016-07-09T11:47:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8dbdf1f5b09cb22560e7c7173b52fe3c631046bd'/>
<id>urn:sha1:8dbdf1f5b09cb22560e7c7173b52fe3c631046bd</id>
<content type='text'>
prsctp PRIO policy is a policy to abandon lower priority chunks when
asoc doesn't have enough snd buffer, so that the current chunk with
higher priority can be queued successfully.

Similar to TTL/RTX policy, we will set the priority of the chunk to
prsctp_param with sinfo-&gt;sinfo_timetolive in sctp_set_prsctp_policy().
So if PRIO policy is enabled, msg-&gt;expire_at won't work.

asoc-&gt;sent_cnt_removable will record how many chunks can be checked to
remove. If priority policy is enabled, when the chunk is queued into
the out_queue, we will increase sent_cnt_removable. When the chunk is
moved to abandon_queue or dequeue and free, we will decrease
sent_cnt_removable.

In sctp_sendmsg, we will check if there is enough snd buffer for current
msg and if sent_cnt_removable is not 0. Then try to abandon chunks in
sctp_prune_prsctp when sendmsg from the retransmit/transmited queue, and
free chunks from out_queue in right order until the abandon+free size &gt;
msg_len - sctp_wfree. For the abandon size, we have to wait until it
sends FORWARD TSN, receives the sack and the chunks are really freed.

Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: avoid refreshing heartbeat timer too often</title>
<updated>2016-04-11T02:22:34Z</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
</author>
<published>2016-04-06T18:15:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ba6f5e33bdbb9ed2014b778fbbaecf20060ca989'/>
<id>urn:sha1:ba6f5e33bdbb9ed2014b778fbbaecf20060ca989</id>
<content type='text'>
Currently on high rate SCTP streams the heartbeat timer refresh can
consume quite a lot of resources as timer updates are costly and it
contains a random factor, which a) is also costly and b) invalidates
mod_timer() optimization for not editing a timer to the same value.
It may even cause the timer to be slightly advanced, for no good reason.

As suggested by David Laight this patch now removes this timer update
from hot path by leaving the timer on and re-evaluating upon its
expiration if the heartbeat is still needed or not, similarly to what is
done for TCP. If it's not needed anymore the timer is re-scheduled to
the new timeout, considering the time already elapsed.

For this, we now record the last tx timestamp per transport, updated in
the same spots as hb timer was restarted on tx. Also split up
sctp_transport_reset_timers into sctp_transport_reset_t3_rtx and
sctp_transport_reset_hb_timer, so we can re-arm T3 without re-arming the
heartbeat one.

On loopback with MTU of 65535 and data chunks with 1636, so that we
have a considerable amount of chunks without stressing system calls,
netperf -t SCTP_STREAM -l 30, perf looked like this before:

Samples: 103K of event 'cpu-clock', Event count (approx.): 25833000000
  Overhead  Command  Shared Object      Symbol
+    6,15%  netperf  [kernel.vmlinux]   [k] copy_user_enhanced_fast_string
-    5,43%  netperf  [kernel.vmlinux]   [k] _raw_write_unlock_irqrestore
   - _raw_write_unlock_irqrestore
      - 96,54% _raw_spin_unlock_irqrestore
         - 36,14% mod_timer
            + 97,24% sctp_transport_reset_timers
            + 2,76% sctp_do_sm
         + 33,65% __wake_up_sync_key
         + 28,77% sctp_ulpq_tail_event
         + 1,40% del_timer
      - 1,84% mod_timer
         + 99,03% sctp_transport_reset_timers
         + 0,97% sctp_do_sm
      + 1,50% sctp_ulpq_tail_event

And after this patch, now with netperf -l 60:

Samples: 230K of event 'cpu-clock', Event count (approx.): 57707250000
  Overhead  Command  Shared Object      Symbol
+    5,65%  netperf  [kernel.vmlinux]   [k] memcpy_erms
+    5,59%  netperf  [kernel.vmlinux]   [k] copy_user_enhanced_fast_string
-    5,05%  netperf  [kernel.vmlinux]   [k] _raw_spin_unlock_irqrestore
   - _raw_spin_unlock_irqrestore
      + 49,89% __wake_up_sync_key
      + 45,68% sctp_ulpq_tail_event
      - 2,85% mod_timer
         + 76,51% sctp_transport_reset_t3_rtx
         + 23,49% sctp_do_sm
      + 1,55% del_timer
+    2,50%  netperf  [sctp]             [k] sctp_datamsg_from_user
+    2,26%  netperf  [sctp]             [k] sctp_sendmsg

Throughput-wise, from 6800mbps without the patch to 7050mbps with it,
~3.7%.

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: do not leak chunks that are sent to unconfirmed paths</title>
<updated>2016-03-20T20:31:12Z</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
</author>
<published>2016-03-18T21:39:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=31b055ef0c6116a27e9a787304ecf87a77d34764'/>
<id>urn:sha1:31b055ef0c6116a27e9a787304ecf87a77d34764</id>
<content type='text'>
Currently, if a chunk is scheduled to be sent through a transport that
is currently unconfirmed, it will be leaked as it is dequeued from outq
and is not re-queued nor freed.

As I'm not aware of any situation that may lead to this situation, I'm
fixing this by freeing the chunk and also logging a trace so that we can
fix the other bug if it ever happens.

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: allow sctp_transmit_packet and others to use gfp</title>
<updated>2016-03-14T02:29:07Z</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
</author>
<published>2016-03-10T21:33:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cea8768f333e3f0bc231d8b815aa4a9e63fa990c'/>
<id>urn:sha1:cea8768f333e3f0bc231d8b815aa4a9e63fa990c</id>
<content type='text'>
Currently sctp_sendmsg() triggers some calls that will allocate memory
with GFP_ATOMIC even when not necessary. In the case of
sctp_packet_transmit it will allocate a linear skb that will be used to
construct the packet and this may cause sends to fail due to ENOMEM more
often than anticipated specially with big MTUs.

This patch thus allows it to inherit gfp flags from upper calls so that
it can use GFP_KERNEL if it was triggered by a sctp_sendmsg call or
similar. All others, like retransmits or flushes started from BH, are
still allocated using GFP_ATOMIC.

In netperf tests this didn't result in any performance drawbacks when
memory is not too fragmented and made it trigger ENOMEM way less often.

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: start t5 timer only when peer rwnd is 0 and local state is SHUTDOWN_PENDING</title>
<updated>2015-12-07T03:31:51Z</updated>
<author>
<name>lucien</name>
</author>
<published>2015-12-05T07:35:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8a0d19c5ed417c78d03f4e0fa7215e58c40896d8'/>
<id>urn:sha1:8a0d19c5ed417c78d03f4e0fa7215e58c40896d8</id>
<content type='text'>
when A sends a data to B, then A close() and enter into SHUTDOWN_PENDING
state, if B neither claim his rwnd is 0 nor send SACK for this data, A
will keep retransmitting this data until t5 timeout, Max.Retrans times
can't work anymore, which is bad.

if B's rwnd is not 0, it should send abort after Max.Retrans times, only
when B's rwnd == 0 and A's retransmitting beyonds Max.Retrans times, A
will start t5 timer, which is also commit f8d960524328 ("sctp: Enforce
retransmission limit during shutdown") means, but it lacks the condition
peer rwnd == 0.

so fix it by adding a bit (zero_window_announced) in peer to record if
the last rwnd is 0. If it was, zero_window_announced will be set. and use
this bit to decide if start t5 timer when local.state is SHUTDOWN_PENDING.

Fixes: commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: hold the chunks only after the chunk is enqueued in outq</title>
<updated>2015-12-06T18:25:12Z</updated>
<author>
<name>lucien</name>
</author>
<published>2015-12-05T07:15:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=69b5777f2e5779bb987d4a25a33401d5ac257c14'/>
<id>urn:sha1:69b5777f2e5779bb987d4a25a33401d5ac257c14</id>
<content type='text'>
When a msg is sent, sctp will hold the chunks of this msg and then try
to enqueue them. But if the chunks are not enqueued in sctp_outq_tail()
because of the invalid state, sctp_cmd_interpreter() may still return
success to sctp_sendmsg() after calling sctp_outq_flush(), these chunks
will become orphans and will leak.

So we fix them by moving sctp_chunk_hold() to sctp_outq_tail(), where we
are sure that the chunk is going to get queued.

Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: sctp: Rename SCTP_XMIT_NAGLE_DELAY to SCTP_XMIT_DELAY</title>
<updated>2014-07-22T20:32:11Z</updated>
<author>
<name>David Laight</name>
</author>
<published>2014-07-22T08:59:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=526cbef778ad8e763b95608d7e5c988b96bf4af5'/>
<id>urn:sha1:526cbef778ad8e763b95608d7e5c988b96bf4af5</id>
<content type='text'>
MSG_MORE and 'corking' a socket would require that the transmit of
a data chunk be delayed.
Rename the return value to be less specific.

Signed-off-by: David Laight &lt;david.laight@aculab.com&gt;
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: sctp: remove unnecessary break after return/goto</title>
<updated>2014-07-15T23:27:01Z</updated>
<author>
<name>Fabian Frederick</name>
</author>
<published>2014-07-14T16:36:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=138ce9102468ef3ad42214b2878004522f357a2a'/>
<id>urn:sha1:138ce9102468ef3ad42214b2878004522f357a2a</id>
<content type='text'>
Signed-off-by: Fabian Frederick &lt;fabf@skynet.be&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
