On Fri, Sep 29, 2017 at 12:54:58PM -0400, Neil Horman wrote: > 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@xxxxxxxxx> > 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? That's my expection as well. If it cannot manage its own throughput, then it should use another scheduler. Marcelo -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
