Re: [PATCH net-next 09/10] sctp: introduce priority based stream scheduler

[Neil Horman <nhorman@tuxdriver.com>]

On Thu, Sep 28, 2017 at 05:25:22PM -0300, Marcelo Ricardo Leitner wrote:
> 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.
> It could be defined as an opaque area like skb->cb, but that would make
> the list handling a nightmare.
> 
> See-also: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-13
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
I presume here that it will be up to the application to rate limit its own
throughput so as to prevent starvation of lower priority streams within an
association?

Neil