Re: [PATCHv2 3/5] sctp: extend socket API for sched configuration

[Yaogong Wang]

The reason is that SCTP supports one-to-many style socket where one
socket handles multiple associations (and hence multiple outqueues).
In that case, if we only store scheduling configurations in the
socket, it may cause several problems:
1. All associations handled by this socket must share the same
scheduling policy.
2. If you change the scheduling algorithm of the socket when some
associations are already established, we have to change the scheduling
of on-going associations, which may be complicated and error-prone.

If we only store scheduling configurations in the association, the
difficulty is: when should the application set these configurations?
In one-to-many style socket, associations are implicitly established.
There isn't a point where association is established but data transfer
hasn't started yet so that the user can configure the scheduling
algorithm. We again has to deal with the problem of changing
scheduling when data transfer is under way.

The current design is a compromise of the two approaches. Scheduling
configurations are set at the socket level and stored in sctp_sock.
When a new association is established, it inherits the scheduling
configurations from the socket. If the application changes the
scheduling configurations of the socket on the fly, only associations
established after the change are affected. That way, we are able to
have different scheduling algorithms for associations handled by one
socket and we eliminate the trouble to change scheduling policy on the
fly.

Thanks,
Yaogong

On Wed, Oct 13, 2010 at 4:31 AM, Shan Wei <shanwei@xxxxxxxxxxxxxx> wrote:
> Yaogong Wang wrote, at 09/12/2010 09:13 AM:
>> Augment SCTP socket API with a new socket option SCTP_SCHED
>> to choose and configure multistream scheduling algorithm.
>>
>> Signed-off-by: Yaogong Wang <ywang15@xxxxxxxx>
>> ---
>>  include/net/sctp/structs.h |    4 ++
>>  include/net/sctp/user.h    |   19 ++++++++++
>>  net/sctp/outqueue.c        |    4 ++
>>  net/sctp/sm_sideeffect.c   |   45 +++++++++++++++++++++++--
>>  net/sctp/socket.c          |   80 ++++++++++++++++++++++++++++++++++++++++++++
>>  5 files changed, 149 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
>> index 52af764..1a76417 100644
>> --- a/include/net/sctp/structs.h
>> +++ b/include/net/sctp/structs.h
>> @@ -333,6 +333,8 @@ struct sctp_sock {
>>
>>       /* Multistream scheduling */
>>       const struct sctp_sched_ops *sched_ops;
>> +     __u16 sched_config_len;
>> +     void *sched_config;
>>
>>       struct sctp_initmsg initmsg;
>>       struct sctp_rtoinfo rtoinfo;
>> @@ -1173,6 +1175,8 @@ struct sctp_outq {
>>
>>       /* Multistream scheduling */
>>       const struct sctp_sched_ops *sched_ops;
>> +     __u16 sched_config_len;
>> +     void *sched_config;
>
> Why did you take these two fields into sctp_sock and sctp_outq?
> These two fields between sctp_sock and sctp_outq has same role,
> we can only defined in one place.
> How about using sctp_sk(sctp_outq->asoc->base.sk) to access these two
> fields?
>
>
> --
> Best Regards
> -----
> Shan Wei
>



-- 
========================
Yaogong Wang, PhD candidate
Department of Computer Science
North Carolina State University
http://www4.ncsu.edu/~ywang15/
========================
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/