1. 12 12月, 2017 4 次提交
  2. 02 12月, 2017 1 次提交
  3. 04 10月, 2017 5 次提交
    • M
      sctp: introduce round robin stream scheduler · ac1ed8b8
      Marcelo Ricardo Leitner 提交于
      This patch introduces RFC Draft ndata section 3.2 Priority Based
      Scheduler (SCTP_SS_RR).
      
      Works by maintaining a list of enqueued streams and tracking the last
      one used to send data. When the datamsg is done, it switches to the next
      stream.
      
      See-also: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-13Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac1ed8b8
    • M
      sctp: introduce priority based stream scheduler · 637784ad
      Marcelo Ricardo Leitner 提交于
      This patch introduces RFC Draft ndata section 3.4 Priority Based
      Scheduler (SCTP_SS_PRIO).
      
      It works by having a struct sctp_stream_priority for each priority
      configured. This struct is then enlisted on a queue ordered per priority
      if, and only if, there is a stream with data queued, so that dequeueing
      is very straightforward: either finish current datamsg or simply dequeue
      from the highest priority queued, which is the next stream pointed, and
      that's it.
      
      If there are multiple streams assigned with the same priority and with
      data queued, it will do round robin amongst them while respecting
      datamsgs boundaries (when not using idata chunks), to be reasonably
      fair.
      
      We intentionally don't maintain a list of priorities nor a list of all
      streams with the same priority to save memory. The first would mean at
      least 2 other pointers per priority (which, for 1000 priorities, that
      can mean 16kB) and the second would also mean 2 other pointers but per
      stream. As SCTP supports up to 65535 streams on a given asoc, that's
      1MB. This impacts when giving a priority to some stream, as we have to
      find out if the new priority is already being used and if we can free
      the old one, and also when tearing down.
      
      The new fields in struct sctp_stream_out_ext and sctp_stream are added
      under a union because that memory is to be shared with other schedulers.
      
      See-also: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-13Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      637784ad
    • M
      sctp: introduce stream scheduler foundations · 5bbbbe32
      Marcelo Ricardo Leitner 提交于
      This patch introduces the hooks necessary to do stream scheduling, as
      per RFC Draft ndata.  It also introduces the first scheduler, which is
      what we do today but now factored out: first come first served (FCFS).
      
      With stream scheduling now we have to track which chunk was enqueued on
      which stream and be able to select another other than the in front of
      the main outqueue. So we introduce a list on sctp_stream_out_ext
      structure for this purpose.
      
      We reuse sctp_chunk->transmitted_list space for the list above, as the
      chunk cannot belong to the two lists at the same time. By using the
      union in there, we can have distinct names for these moments.
      
      sctp_sched_ops are the operations expected to be implemented by each
      scheduler. The dequeueing is a bit particular to this implementation but
      it is to match how we dequeue packets today. We first dequeue and then
      check if it fits the packet and if not, we requeue it at head. Thus why
      we don't have a peek operation but have dequeue_done instead, which is
      called once the chunk can be safely considered as transmitted.
      
      The check removed from sctp_outq_flush is now performed by
      sctp_stream_outq_migrate, which is only called during assoc setup.
      (sctp_sendmsg() also checks for it)
      
      The only operation that is foreseen but not yet added here is a way to
      signalize that a new packet is starting or that the packet is done, for
      round robin scheduler per packet, but is intentionally left to the
      patch that actually implements it.
      
      Support for I-DATA chunks, also described in this RFC, with user message
      interleaving is straightforward as it just requires the schedulers to
      probe for the feature and ignore datamsg boundaries when dequeueing.
      
      See-also: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-13Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5bbbbe32
    • M
      sctp: introduce sctp_chunk_stream_no · 2fc019f7
      Marcelo Ricardo Leitner 提交于
      Add a helper to fetch the stream number from a given chunk.
      Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fc019f7
    • M
      sctp: introduce struct sctp_stream_out_ext · f952be79
      Marcelo Ricardo Leitner 提交于
      With the stream schedulers, sctp_stream_out will become too big to be
      allocated by kmalloc and as we need to allocate with BH disabled, we
      cannot use __vmalloc in sctp_stream_init().
      
      This patch moves out the stats from sctp_stream_out to
      sctp_stream_out_ext, which will be allocated only when the application
      tries to sendmsg something on it.
      
      Just the introduction of sctp_stream_out_ext would already fix the issue
      described above by splitting the allocation in two. Moving the stats
      to it also reduces the pressure on the allocator as we will ask for less
      memory atomically when creating the socket and we will use GFP_KERNEL
      later.
      
      Then, for stream schedulers, we will just use sctp_stream_out_ext.
      Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f952be79
  4. 12 8月, 2017 6 次提交
  5. 07 8月, 2017 6 次提交
  6. 17 7月, 2017 3 次提交
  7. 05 7月, 2017 4 次提交
  8. 02 7月, 2017 3 次提交
  9. 21 6月, 2017 1 次提交
  10. 03 6月, 2017 2 次提交
  11. 19 4月, 2017 1 次提交
    • X
      sctp: process duplicated strreset out and addstrm out requests correctly · e4dc99c7
      Xin Long 提交于
      Now sctp stream reconf will process a request again even if it's seqno is
      less than asoc->strreset_inseq.
      
      If one request has been done successfully and some data chunks have been
      accepted and then a duplicated strreset out request comes, the streamin's
      ssn will be cleared. It will cause that stream will never receive chunks
      any more because of unsynchronized ssn. It allows a replay attack.
      
      A similar issue also exists when processing addstrm out requests. It will
      cause more extra streams being added.
      
      This patch is to fix it by saving the last 2 results into asoc. When a
      duplicated strreset out or addstrm out request is received, reply it with
      bad seqno if it's seqno < asoc->strreset_inseq - 2, and reply it with the
      result saved in asoc if it's seqno >= asoc->strreset_inseq - 2.
      
      Note that it saves last 2 results instead of only last 1 result, because
      two requests can be sent together in one chunk.
      
      And note that when receiving a duplicated request, the receiver side will
      still reply it even if the peer has received the response. It's safe, As
      the response will be dropped by the peer.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4dc99c7
  12. 05 4月, 2017 1 次提交
  13. 04 4月, 2017 1 次提交
  14. 31 3月, 2017 1 次提交
    • X
      sctp: alloc stream info when initializing asoc · 3dbcc105
      Xin Long 提交于
      When sending a msg without asoc established, sctp will send INIT packet
      first and then enqueue chunks.
      
      Before receiving INIT_ACK, stream info is not yet alloced. But enqueuing
      chunks needs to access stream info, like out stream state and out stream
      cnt.
      
      This patch is to fix it by allocing out stream info when initializing an
      asoc, allocing in stream and re-allocing out stream when processing init.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3dbcc105
  15. 29 3月, 2017 1 次提交
    • X
      sctp: change to save MSG_MORE flag into assoc · f9ba3501
      Xin Long 提交于
      David Laight noticed the support for MSG_MORE with datamsg->force_delay
      didn't really work as we expected, as the first msg with MSG_MORE set
      would always block the following chunks' dequeuing.
      
      This Patch is to rewrite it by saving the MSG_MORE flag into assoc as
      David Laight suggested.
      
      asoc->force_delay is used to save MSG_MORE flag before a msg is sent.
      All chunks in queue would not be sent out if asoc->force_delay is set
      by the msg with MSG_MORE flag, until a new msg without MSG_MORE flag
      clears asoc->force_delay.
      
      Note that this change would not affect the flush is generated by other
      triggers, like asoc->state != ESTABLISHED, queue size > pmtu etc.
      
      v1->v2:
        Not clear asoc->force_delay after sending the msg with MSG_MORE flag.
      
      Fixes: 4ea0c32f ("sctp: add support for MSG_MORE")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NDavid Laight <david.laight@aculab.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9ba3501