Wei Yongjun wrote:
> Vlad Yasevich wrote:
>> If the association has a SACK timer pending and now DATA queued
>> to be send, we'll try to bundle the SACK with the next application send.
>> As such, try encourage bundling by accounting for SACK in the size
>> of the first chunk fragment.
>>
>> Signed-off-by: Vlad Yasevich <vladislav.yasevich@xxxxxx>
>> ---
>> net/sctp/chunk.c | 9 +++++++++
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
>> index 1748ef9..05b532e 100644
>> --- a/net/sctp/chunk.c
>> +++ b/net/sctp/chunk.c
>> @@ -196,6 +196,15 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
>> whole = 0;
>> first_len = max;
>>
>> + /* Check to see if we have a pending SACK and try to let it be bundled
>> + * with this message. Do this if we don't have any data queued already.
>> + * To check that, look at out_qlen and retransmit list.
>> + */
>> + if (timer_pending(&asoc->timers[SCTP_EVENT_TIMEOUT_SACK]) &&
>> + asoc->outqueue.out_qlen == 0 &&
>> + list_empty(&asoc->outqueue.retransmit))
>> + first_len -= WORD_ROUND(sizeof(sctp_sack_chunk_t));
>> +
>>
>
> Maybe we should check the first_len < WORD_ROUND(sizeof(sctp_sack_chunk_t)).
> Some time when first_len = asoc->frag_point - AUTH_CHUNK - SACK_CHUNK, if
> the user set the frag_point to a low value such as 40, the first_len will
> be negative value.
> The same problem exists when we hold the room for AUTH chunk.
>
> I have checked that asoc->frag_point can be set between 8 and
> SCTP_MAX_CHUNK_LEN.
>
Good point. Will do.
-vlad
>
>
>> /* Encourage Cookie-ECHO bundling. */
>> if (asoc->state < SCTP_STATE_COOKIE_ECHOED) {
>> whole = msg_len / (max - SCTP_ARBITRARY_COOKIE_ECHO_LEN);
>>
>
>
--
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
