<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/sctp/inqueue.c, branch v4.13</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>sctp: remove the typedef sctp_chunkhdr_t</title>
<updated>2017-07-01T16:08:41+00:00</updated>
<author>
<name>Xin Long</name>
<email>lucien.xin@gmail.com</email>
</author>
<published>2017-06-30T03:52:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=922dbc5be2186659d2c453a53f2ae569e55b6101'/>
<id>922dbc5be2186659d2c453a53f2ae569e55b6101</id>
<content type='text'>
This patch is to remove the typedef sctp_chunkhdr_t, and replace
with struct sctp_chunkhdr in the places where it's using this
typedef.

It is also to fix some indents and use sizeof(variable) instead
of sizeof(type)., especially in sctp_new.

Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is to remove the typedef sctp_chunkhdr_t, and replace
with struct sctp_chunkhdr in the places where it's using this
typedef.

It is also to fix some indents and use sizeof(variable) instead
of sizeof(type)., especially in sctp_new.

Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: rename WORD_TRUNC/ROUND macros</title>
<updated>2016-09-22T07:13:26+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>marcelo.leitner@gmail.com</email>
</author>
<published>2016-09-21T11:45:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e2f036a97271cf5811ee754bf321a29a814577f9'/>
<id>e2f036a97271cf5811ee754bf321a29a814577f9</id>
<content type='text'>
To something more meaningful these days, specially because this is
working on packet headers or lengths and which are not tied to any CPU
arch but to the protocol itself.

So, WORD_TRUNC becomes SCTP_TRUNC4 and WORD_ROUND becomes SCTP_PAD4.

Reported-by: David Laight &lt;David.Laight@ACULAB.COM&gt;
Reported-by: David Miller &lt;davem@davemloft.net&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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To something more meaningful these days, specially because this is
working on packet headers or lengths and which are not tied to any CPU
arch but to the protocol itself.

So, WORD_TRUNC becomes SCTP_TRUNC4 and WORD_ROUND becomes SCTP_PAD4.

Reported-by: David Laight &lt;David.Laight@ACULAB.COM&gt;
Reported-by: David Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: linearize early if it's not GSO</title>
<updated>2016-08-20T00:09:42+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>marcelo.leitner@gmail.com</email>
</author>
<published>2016-08-18T17:58:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4c2f2454964477c66ef57745daab203b71783f66'/>
<id>4c2f2454964477c66ef57745daab203b71783f66</id>
<content type='text'>
Because otherwise when crc computation is still needed it's way more
expensive than on a linear buffer to the point that it affects
performance.

It's so expensive that netperf test gives a perf output as below:

Overhead  Command         Shared Object       Symbol
  18,62%  netserver       [kernel.vmlinux]    [k] crc32_generic_shift
   2,57%  netserver       [kernel.vmlinux]    [k] __pskb_pull_tail
   1,94%  netserver       [kernel.vmlinux]    [k] fib_table_lookup
   1,90%  netserver       [kernel.vmlinux]    [k] copy_user_enhanced_fast_string
   1,66%  swapper         [kernel.vmlinux]    [k] intel_idle
   1,63%  netserver       [kernel.vmlinux]    [k] _raw_spin_lock
   1,59%  netserver       [sctp]              [k] sctp_packet_transmit
   1,55%  netserver       [kernel.vmlinux]    [k] memcpy_erms
   1,42%  netserver       [sctp]              [k] sctp_rcv

# netperf -H 192.168.10.1 -l 10 -t SCTP_STREAM -cC -- -m 12000
SCTP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.1 () port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

212992 212992  12000    10.00      3016.42   2.88     3.78     1.874   2.462

After patch:
Overhead  Command         Shared Object      Symbol
   2,75%  netserver       [kernel.vmlinux]   [k] memcpy_erms
   2,63%  netserver       [kernel.vmlinux]   [k] copy_user_enhanced_fast_string
   2,39%  netserver       [kernel.vmlinux]   [k] fib_table_lookup
   2,04%  netserver       [kernel.vmlinux]   [k] __pskb_pull_tail
   1,91%  netserver       [kernel.vmlinux]   [k] _raw_spin_lock
   1,91%  netserver       [sctp]             [k] sctp_packet_transmit
   1,72%  netserver       [mlx4_en]          [k] mlx4_en_process_rx_cq
   1,68%  netserver       [sctp]             [k] sctp_rcv

# netperf -H 192.168.10.1 -l 10 -t SCTP_STREAM -cC -- -m 12000
SCTP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.1 () port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

212992 212992  12000    10.00      3681.77   3.83     3.46     2.045   1.849

Fixes: 3acb50c18d8d ("sctp: delay as much as possible skb_linearize")
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Because otherwise when crc computation is still needed it's way more
expensive than on a linear buffer to the point that it affects
performance.

It's so expensive that netperf test gives a perf output as below:

Overhead  Command         Shared Object       Symbol
  18,62%  netserver       [kernel.vmlinux]    [k] crc32_generic_shift
   2,57%  netserver       [kernel.vmlinux]    [k] __pskb_pull_tail
   1,94%  netserver       [kernel.vmlinux]    [k] fib_table_lookup
   1,90%  netserver       [kernel.vmlinux]    [k] copy_user_enhanced_fast_string
   1,66%  swapper         [kernel.vmlinux]    [k] intel_idle
   1,63%  netserver       [kernel.vmlinux]    [k] _raw_spin_lock
   1,59%  netserver       [sctp]              [k] sctp_packet_transmit
   1,55%  netserver       [kernel.vmlinux]    [k] memcpy_erms
   1,42%  netserver       [sctp]              [k] sctp_rcv

# netperf -H 192.168.10.1 -l 10 -t SCTP_STREAM -cC -- -m 12000
SCTP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.1 () port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

212992 212992  12000    10.00      3016.42   2.88     3.78     1.874   2.462

After patch:
Overhead  Command         Shared Object      Symbol
   2,75%  netserver       [kernel.vmlinux]   [k] memcpy_erms
   2,63%  netserver       [kernel.vmlinux]   [k] copy_user_enhanced_fast_string
   2,39%  netserver       [kernel.vmlinux]   [k] fib_table_lookup
   2,04%  netserver       [kernel.vmlinux]   [k] __pskb_pull_tail
   1,91%  netserver       [kernel.vmlinux]   [k] _raw_spin_lock
   1,91%  netserver       [sctp]             [k] sctp_packet_transmit
   1,72%  netserver       [mlx4_en]          [k] mlx4_en_process_rx_cq
   1,68%  netserver       [sctp]             [k] sctp_rcv

# netperf -H 192.168.10.1 -l 10 -t SCTP_STREAM -cC -- -m 12000
SCTP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.1 () port 0 AF_INET
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

212992 212992  12000    10.00      3681.77   3.83     3.46     2.045   1.849

Fixes: 3acb50c18d8d ("sctp: delay as much as possible skb_linearize")
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: fix BH handling on socket backlog</title>
<updated>2016-07-25T18:22:22+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>marcelo.leitner@gmail.com</email>
</author>
<published>2016-07-23T03:32:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=eefc1b1d105ee4d2ce907833ce675f1e9599b5e3'/>
<id>eefc1b1d105ee4d2ce907833ce675f1e9599b5e3</id>
<content type='text'>
Now that the backlog processing is called with BH enabled, we have to
disable BH before taking the socket lock via bh_lock_sock() otherwise
it may dead lock:

sctp_backlog_rcv()
                bh_lock_sock(sk);

                if (sock_owned_by_user(sk)) {
                        if (sk_add_backlog(sk, skb, sk-&gt;sk_rcvbuf))
                                sctp_chunk_free(chunk);
                        else
                                backloged = 1;
                } else
                        sctp_inq_push(inqueue, chunk);

                bh_unlock_sock(sk);

while sctp_inq_push() was disabling/enabling BH, but enabling BH
triggers pending softirq, which then may try to re-lock the socket in
sctp_rcv().

[  219.187215]  &lt;IRQ&gt;
[  219.187217]  [&lt;ffffffff817ca3e0&gt;] _raw_spin_lock+0x20/0x30
[  219.187223]  [&lt;ffffffffa041888c&gt;] sctp_rcv+0x48c/0xba0 [sctp]
[  219.187225]  [&lt;ffffffff816e7db2&gt;] ? nf_iterate+0x62/0x80
[  219.187226]  [&lt;ffffffff816f1b14&gt;] ip_local_deliver_finish+0x94/0x1e0
[  219.187228]  [&lt;ffffffff816f1e1f&gt;] ip_local_deliver+0x6f/0xf0
[  219.187229]  [&lt;ffffffff816f1a80&gt;] ? ip_rcv_finish+0x3b0/0x3b0
[  219.187230]  [&lt;ffffffff816f17a8&gt;] ip_rcv_finish+0xd8/0x3b0
[  219.187232]  [&lt;ffffffff816f2122&gt;] ip_rcv+0x282/0x3a0
[  219.187233]  [&lt;ffffffff810d8bb6&gt;] ? update_curr+0x66/0x180
[  219.187235]  [&lt;ffffffff816abac4&gt;] __netif_receive_skb_core+0x524/0xa90
[  219.187236]  [&lt;ffffffff810d8e00&gt;] ? update_cfs_shares+0x30/0xf0
[  219.187237]  [&lt;ffffffff810d557c&gt;] ? __enqueue_entity+0x6c/0x70
[  219.187239]  [&lt;ffffffff810dc454&gt;] ? enqueue_entity+0x204/0xdf0
[  219.187240]  [&lt;ffffffff816ac048&gt;] __netif_receive_skb+0x18/0x60
[  219.187242]  [&lt;ffffffff816ad1ce&gt;] process_backlog+0x9e/0x140
[  219.187243]  [&lt;ffffffff816ac8ec&gt;] net_rx_action+0x22c/0x370
[  219.187245]  [&lt;ffffffff817cd352&gt;] __do_softirq+0x112/0x2e7
[  219.187247]  [&lt;ffffffff817cc3bc&gt;] do_softirq_own_stack+0x1c/0x30
[  219.187247]  &lt;EOI&gt;
[  219.187248]  [&lt;ffffffff810aa1c8&gt;] do_softirq.part.14+0x38/0x40
[  219.187249]  [&lt;ffffffff810aa24d&gt;] __local_bh_enable_ip+0x7d/0x80
[  219.187254]  [&lt;ffffffffa0408428&gt;] sctp_inq_push+0x68/0x80 [sctp]
[  219.187258]  [&lt;ffffffffa04190f1&gt;] sctp_backlog_rcv+0x151/0x1c0 [sctp]
[  219.187260]  [&lt;ffffffff81692b07&gt;] __release_sock+0x87/0xf0
[  219.187261]  [&lt;ffffffff81692ba0&gt;] release_sock+0x30/0xa0
[  219.187265]  [&lt;ffffffffa040e46d&gt;] sctp_accept+0x17d/0x210 [sctp]
[  219.187266]  [&lt;ffffffff810e7510&gt;] ? prepare_to_wait_event+0xf0/0xf0
[  219.187268]  [&lt;ffffffff8172d52c&gt;] inet_accept+0x3c/0x130
[  219.187269]  [&lt;ffffffff8168d7a3&gt;] SYSC_accept4+0x103/0x210
[  219.187271]  [&lt;ffffffff817ca2ba&gt;] ? _raw_spin_unlock_bh+0x1a/0x20
[  219.187272]  [&lt;ffffffff81692bfc&gt;] ? release_sock+0x8c/0xa0
[  219.187276]  [&lt;ffffffffa0413e22&gt;] ? sctp_inet_listen+0x62/0x1b0 [sctp]
[  219.187277]  [&lt;ffffffff8168f2d0&gt;] SyS_accept+0x10/0x20

Fixes: 860fbbc343bf ("sctp: prepare for socket backlog behavior change")
Cc: Eric Dumazet &lt;eric.dumazet@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that the backlog processing is called with BH enabled, we have to
disable BH before taking the socket lock via bh_lock_sock() otherwise
it may dead lock:

sctp_backlog_rcv()
                bh_lock_sock(sk);

                if (sock_owned_by_user(sk)) {
                        if (sk_add_backlog(sk, skb, sk-&gt;sk_rcvbuf))
                                sctp_chunk_free(chunk);
                        else
                                backloged = 1;
                } else
                        sctp_inq_push(inqueue, chunk);

                bh_unlock_sock(sk);

while sctp_inq_push() was disabling/enabling BH, but enabling BH
triggers pending softirq, which then may try to re-lock the socket in
sctp_rcv().

[  219.187215]  &lt;IRQ&gt;
[  219.187217]  [&lt;ffffffff817ca3e0&gt;] _raw_spin_lock+0x20/0x30
[  219.187223]  [&lt;ffffffffa041888c&gt;] sctp_rcv+0x48c/0xba0 [sctp]
[  219.187225]  [&lt;ffffffff816e7db2&gt;] ? nf_iterate+0x62/0x80
[  219.187226]  [&lt;ffffffff816f1b14&gt;] ip_local_deliver_finish+0x94/0x1e0
[  219.187228]  [&lt;ffffffff816f1e1f&gt;] ip_local_deliver+0x6f/0xf0
[  219.187229]  [&lt;ffffffff816f1a80&gt;] ? ip_rcv_finish+0x3b0/0x3b0
[  219.187230]  [&lt;ffffffff816f17a8&gt;] ip_rcv_finish+0xd8/0x3b0
[  219.187232]  [&lt;ffffffff816f2122&gt;] ip_rcv+0x282/0x3a0
[  219.187233]  [&lt;ffffffff810d8bb6&gt;] ? update_curr+0x66/0x180
[  219.187235]  [&lt;ffffffff816abac4&gt;] __netif_receive_skb_core+0x524/0xa90
[  219.187236]  [&lt;ffffffff810d8e00&gt;] ? update_cfs_shares+0x30/0xf0
[  219.187237]  [&lt;ffffffff810d557c&gt;] ? __enqueue_entity+0x6c/0x70
[  219.187239]  [&lt;ffffffff810dc454&gt;] ? enqueue_entity+0x204/0xdf0
[  219.187240]  [&lt;ffffffff816ac048&gt;] __netif_receive_skb+0x18/0x60
[  219.187242]  [&lt;ffffffff816ad1ce&gt;] process_backlog+0x9e/0x140
[  219.187243]  [&lt;ffffffff816ac8ec&gt;] net_rx_action+0x22c/0x370
[  219.187245]  [&lt;ffffffff817cd352&gt;] __do_softirq+0x112/0x2e7
[  219.187247]  [&lt;ffffffff817cc3bc&gt;] do_softirq_own_stack+0x1c/0x30
[  219.187247]  &lt;EOI&gt;
[  219.187248]  [&lt;ffffffff810aa1c8&gt;] do_softirq.part.14+0x38/0x40
[  219.187249]  [&lt;ffffffff810aa24d&gt;] __local_bh_enable_ip+0x7d/0x80
[  219.187254]  [&lt;ffffffffa0408428&gt;] sctp_inq_push+0x68/0x80 [sctp]
[  219.187258]  [&lt;ffffffffa04190f1&gt;] sctp_backlog_rcv+0x151/0x1c0 [sctp]
[  219.187260]  [&lt;ffffffff81692b07&gt;] __release_sock+0x87/0xf0
[  219.187261]  [&lt;ffffffff81692ba0&gt;] release_sock+0x30/0xa0
[  219.187265]  [&lt;ffffffffa040e46d&gt;] sctp_accept+0x17d/0x210 [sctp]
[  219.187266]  [&lt;ffffffff810e7510&gt;] ? prepare_to_wait_event+0xf0/0xf0
[  219.187268]  [&lt;ffffffff8172d52c&gt;] inet_accept+0x3c/0x130
[  219.187269]  [&lt;ffffffff8168d7a3&gt;] SYSC_accept4+0x103/0x210
[  219.187271]  [&lt;ffffffff817ca2ba&gt;] ? _raw_spin_unlock_bh+0x1a/0x20
[  219.187272]  [&lt;ffffffff81692bfc&gt;] ? release_sock+0x8c/0xa0
[  219.187276]  [&lt;ffffffffa0413e22&gt;] ? sctp_inet_listen+0x62/0x1b0 [sctp]
[  219.187277]  [&lt;ffffffff8168f2d0&gt;] SyS_accept+0x10/0x20

Fixes: 860fbbc343bf ("sctp: prepare for socket backlog behavior change")
Cc: Eric Dumazet &lt;eric.dumazet@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: do not clear chunk-&gt;ecn_ce_done flag</title>
<updated>2016-07-14T01:10:14+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>marcelo.leitner@gmail.com</email>
</author>
<published>2016-07-13T18:08:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d9cef42529402f9fce10376b6e427a5137d90c3d'/>
<id>d9cef42529402f9fce10376b6e427a5137d90c3d</id>
<content type='text'>
We should not clear that flag when switching to a new skb from a GSO skb
because it would cause ECN processing to happen multiple times per GSO
skb, which is not wanted. Instead, let it be processed once per chunk.
That is, in other words, once per IP header available.

Fixes: 90017accff61 ("sctp: Add GSO support")
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We should not clear that flag when switching to a new skb from a GSO skb
because it would cause ECN processing to happen multiple times per GSO
skb, which is not wanted. Instead, let it be processed once per chunk.
That is, in other words, once per IP header available.

Fixes: 90017accff61 ("sctp: Add GSO support")
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: avoid identifying address family many times for a chunk</title>
<updated>2016-07-14T01:10:14+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>marcelo.leitner@gmail.com</email>
</author>
<published>2016-07-13T18:08:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e7487c86dc5c4a528a7dbd9dc14f453a0de61a84'/>
<id>e7487c86dc5c4a528a7dbd9dc14f453a0de61a84</id>
<content type='text'>
Identifying address family operations during rx path is not something
expensive but it's ugly to the eye to have it done multiple times,
specially when we already validated it during initial rx processing.

This patch takes advantage of the now shared sctp_input_cb and make the
pointer to the operations readily available.

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Identifying address family operations during rx path is not something
expensive but it's ugly to the eye to have it done multiple times,
specially when we already validated it during initial rx processing.

This patch takes advantage of the now shared sctp_input_cb and make the
pointer to the operations readily available.

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: allow GSO frags to access the chunk too</title>
<updated>2016-07-14T01:10:14+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>marcelo.leitner@gmail.com</email>
</author>
<published>2016-07-13T18:08:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1f45f78f8e511203f03138f2ccde3d2cf90d2cbf'/>
<id>1f45f78f8e511203f03138f2ccde3d2cf90d2cbf</id>
<content type='text'>
SCTP will try to access original IP headers on sctp_recvmsg in order to
copy the addresses used. There are also other places that do similar access
to IP or even SCTP headers. But after 90017accff61 ("sctp: Add GSO
support") they aren't always there because they are only present in the
header skb.

SCTP handles the queueing of incoming data by cloning the incoming skb
and limiting to only the relevant payload. This clone has its cb updated
to something different and it's then queued on socket rx queue. Thus we
need to fix this in two moments.

For rx path, not related to socket queue yet, this patch uses a
partially copied sctp_input_cb to such GSO frags. This restores the
ability to access the headers for this part of the code.

Regarding the socket rx queue, it removes iif member from sctp_event and
also add a chunk pointer on it.

With these changes we're always able to reach the headers again.

The biggest change here is that now the sctp_chunk struct and the
original skb are only freed after the application consumed the buffer.
Note however that the original payload was already like this due to the
skb cloning.

For iif, SCTP's IPv4 code doesn't use it, so no change is necessary.
IPv6 now can fetch it directly from original's IPv6 CB as the original
skb is still accessible.

In the future we probably can simplify sctp_v*_skb_iif() stuff, as
sctp_v4_skb_iif() was called but it's return value not used, and now
it's not even called, but such cleanup is out of scope for this change.

Fixes: 90017accff61 ("sctp: Add GSO support")
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SCTP will try to access original IP headers on sctp_recvmsg in order to
copy the addresses used. There are also other places that do similar access
to IP or even SCTP headers. But after 90017accff61 ("sctp: Add GSO
support") they aren't always there because they are only present in the
header skb.

SCTP handles the queueing of incoming data by cloning the incoming skb
and limiting to only the relevant payload. This clone has its cb updated
to something different and it's then queued on socket rx queue. Thus we
need to fix this in two moments.

For rx path, not related to socket queue yet, this patch uses a
partially copied sctp_input_cb to such GSO frags. This restores the
ability to access the headers for this part of the code.

Regarding the socket rx queue, it removes iif member from sctp_event and
also add a chunk pointer on it.

With these changes we're always able to reach the headers again.

The biggest change here is that now the sctp_chunk struct and the
original skb are only freed after the application consumed the buffer.
Note however that the original payload was already like this due to the
skb cloning.

For iif, SCTP's IPv4 code doesn't use it, so no change is necessary.
IPv6 now can fetch it directly from original's IPv6 CB as the original
skb is still accessible.

In the future we probably can simplify sctp_v*_skb_iif() stuff, as
sctp_v4_skb_iif() was called but it's return value not used, and now
it's not even called, but such cleanup is out of scope for this change.

Fixes: 90017accff61 ("sctp: Add GSO support")
Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: Add GSO support</title>
<updated>2016-06-03T23:37:21+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>marcelo.leitner@gmail.com</email>
</author>
<published>2016-06-02T18:05:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=90017accff61ae89283ad9a51f9ac46ca01633fb'/>
<id>90017accff61ae89283ad9a51f9ac46ca01633fb</id>
<content type='text'>
SCTP has this pecualiarity that its packets cannot be just segmented to
(P)MTU. Its chunks must be contained in IP segments, padding respected.
So we can't just generate a big skb, set gso_size to the fragmentation
point and deliver it to IP layer.

This patch takes a different approach. SCTP will now build a skb as it
would be if it was received using GRO. That is, there will be a cover
skb with protocol headers and children ones containing the actual
segments, already segmented to a way that respects SCTP RFCs.

With that, we can tell skb_segment() to just split based on frag_list,
trusting its sizes are already in accordance.

This way SCTP can benefit from GSO and instead of passing several
packets through the stack, it can pass a single large packet.

v2:
- Added support for receiving GSO frames, as requested by Dave Miller.
- Clear skb-&gt;cb if packet is GSO (otherwise it's not used by SCTP)
- Added heuristics similar to what we have in TCP for not generating
  single GSO packets that fills cwnd.
v3:
- consider sctphdr size in skb_gso_transport_seglen()
- rebased due to 5c7cdf339af5 ("gso: Remove arbitrary checks for
  unsupported GSO")

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Tested-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SCTP has this pecualiarity that its packets cannot be just segmented to
(P)MTU. Its chunks must be contained in IP segments, padding respected.
So we can't just generate a big skb, set gso_size to the fragmentation
point and deliver it to IP layer.

This patch takes a different approach. SCTP will now build a skb as it
would be if it was received using GRO. That is, there will be a cover
skb with protocol headers and children ones containing the actual
segments, already segmented to a way that respects SCTP RFCs.

With that, we can tell skb_segment() to just split based on frag_list,
trusting its sizes are already in accordance.

This way SCTP can benefit from GSO and instead of passing several
packets through the stack, it can pass a single large packet.

v2:
- Added support for receiving GSO frames, as requested by Dave Miller.
- Clear skb-&gt;cb if packet is GSO (otherwise it's not used by SCTP)
- Added heuristics similar to what we have in TCP for not generating
  single GSO packets that fills cwnd.
v3:
- consider sctphdr size in skb_gso_transport_seglen()
- rebased due to 5c7cdf339af5 ("gso: Remove arbitrary checks for
  unsupported GSO")

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Tested-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: delay as much as possible skb_linearize</title>
<updated>2016-06-03T23:37:21+00:00</updated>
<author>
<name>Marcelo Ricardo Leitner</name>
<email>marcelo.leitner@gmail.com</email>
</author>
<published>2016-06-02T18:05:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3acb50c18d8d6650f10919464ade4dcdaf41d62f'/>
<id>3acb50c18d8d6650f10919464ade4dcdaf41d62f</id>
<content type='text'>
This patch is a preparation for the GSO one. In order to successfully
handle GSO packets on rx path we must not call skb_linearize, otherwise
it defeats any gain GSO may have had.

This patch thus delays as much as possible the call to skb_linearize,
leaving it to sctp_inq_pop() moment. For that the sanity checks
performed now know how to deal with fragments.

One positive side-effect of this is that if the socket is backlogged it
will have the chance of doing it on backlog processing instead of
during softirq.

With this move, it's evident that a check for non-linearity in
sctp_inq_pop was ineffective and is now removed. Note that a similar
check is performed a bit below this one.

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Tested-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is a preparation for the GSO one. In order to successfully
handle GSO packets on rx path we must not call skb_linearize, otherwise
it defeats any gain GSO may have had.

This patch thus delays as much as possible the call to skb_linearize,
leaving it to sctp_inq_pop() moment. For that the sanity checks
performed now know how to deal with fragments.

One positive side-effect of this is that if the socket is backlogged it
will have the chance of doing it on backlog processing instead of
during softirq.

With this move, it's evident that a check for non-linearity in
sctp_inq_pop was ineffective and is now removed. Note that a similar
check is performed a bit below this one.

Signed-off-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Tested-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sctp: prepare for socket backlog behavior change</title>
<updated>2016-05-02T21:02:26+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2016-04-29T21:16:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=860fbbc343bf05a71b31555579ff4878194be01b'/>
<id>860fbbc343bf05a71b31555579ff4878194be01b</id>
<content type='text'>
sctp_inq_push() will soon be called without BH being blocked
when generic socket code flushes the socket backlog.

It is very possible SCTP can be converted to not rely on BH,
but this needs to be done by SCTP experts.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
sctp_inq_push() will soon be called without BH being blocked
when generic socket code flushes the socket backlog.

It is very possible SCTP can be converted to not rely on BH,
but this needs to be done by SCTP experts.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
