All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chang <changxiangzhong@gmail.com>
To: Vlad Yasevich <vyasevich@gmail.com>,
	nhorman@tuxdriver.com, davem@davemloft.net
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: sctp: set chunk->tsn_gap_acked at the end of cycle
Date: Sat, 23 Nov 2013 08:22:11 +0000	[thread overview]
Message-ID: <529065B3.6060905@gmail.com> (raw)
In-Reply-To: <528FDF52.4030500@gmail.com>


On 11/22/2013 11:48 PM, Vlad Yasevich wrote:
> On 11/22/2013 02:24 PM, Chang wrote:
>> On 11/22/2013 03:27 PM, Vlad Yasevich wrote:
>>> On 11/22/2013 02:49 AM, Chang Xiangzhong wrote:
>>>> tsn_gap_acked is an important state flag in chunk, which indicates if
>>>> the
>>>> chunk has been acked in gap reports before.
>>> Actually, this bit indicates simply that the chunk has been acked.  It
>>> doesn't state whether it's been acked in a gap report or via
>>> cumulative tsn.
>> Thanks for pointing this out. Sorry for not having made that clear.
>>>> SFR-CACC algorithm depends on this
>>>> variable. So set this at the end of each iteration, otherwise the
>>>> SFR-CACC
>>>> algorithm would never be toggled.
>>>>
>>>> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
>>>> ---
>>>>    net/sctp/outqueue.c | 3 ++-
>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>>>> index 1b494fa..bff828c 100644
>>>> --- a/net/sctp/outqueue.c
>>>> +++ b/net/sctp/outqueue.c
>>>> @@ -1396,7 +1396,6 @@ static void sctp_check_transmitted(struct
>>>> sctp_outq *q,
>>>>                 * while DATA was outstanding).
>>>>                 */
>>>>                if (!tchunk->tsn_gap_acked) {
>>>> -                tchunk->tsn_gap_acked = 1;
>>>>                    if (TSN_lt(*highest_new_tsn_in_sack, tsn))
>>>>                        *highest_new_tsn_in_sack = tsn;
>>>>                    bytes_acked += sctp_data_size(tchunk);
>>>> @@ -1460,6 +1459,8 @@ static void sctp_check_transmitted(struct
>>>> sctp_outq *q,
>>>>                     */
>>>>                    list_add_tail(lchunk, &tlist);
>>>>                }
>>>> +
>>>> +            tchunk->tsn_gap_acked = 1;
>>> The current code will set the state if it hasn't been set yet.  Why is
>>> this needed?
>> Because in line 1420 ~ 1440 The SFR-CACC algorithms use tsn_gap_acked.
>> That "if block" would never be triggered because the varaiable's been
>> set. That's why I move the "state changing sentence" to the end of the
>> iteration.
>>> Now there is an issue with tracking highest_new_tsn_in_sack.  The spec
>>> is a little vague on this, but the highest_new_tsn_in_sack only supposed
>>> to track tsns that have not been resent.  If a tsn has been reneged, and
>>> then sent again, it is not considered 'new' thus should not count
>>> toward highest_new_tsn_in_sack.  We currently do not track this right.
>> I'll try to figure this out.
> So the solution that's been proposed before is to move the CACC block up
> and merge it with the !tsn_gap_acked block.  This requires additional
> change though to only mark highest_new_tsn if the chunk has not been
> retransmitted (which you've added in a prior patch).
>
> -vlad
Yeah, I've mixed that up with a prior patch. How was the previous patch? 
Was it approved?
-chang
>>> -vlad
>>>
>>> -vlad
>>>
>>>>            } else {
>>>>                if (tchunk->tsn_gap_acked) {
>>>>                    pr_debug("%s: receiver reneged on data TSN:0x%x\n",
>>>>


WARNING: multiple messages have this Message-ID (diff)
From: Chang <changxiangzhong@gmail.com>
To: Vlad Yasevich <vyasevich@gmail.com>,
	nhorman@tuxdriver.com, davem@davemloft.net
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: sctp: set chunk->tsn_gap_acked at the end of cycle
Date: Sat, 23 Nov 2013 09:22:11 +0100	[thread overview]
Message-ID: <529065B3.6060905@gmail.com> (raw)
In-Reply-To: <528FDF52.4030500@gmail.com>


On 11/22/2013 11:48 PM, Vlad Yasevich wrote:
> On 11/22/2013 02:24 PM, Chang wrote:
>> On 11/22/2013 03:27 PM, Vlad Yasevich wrote:
>>> On 11/22/2013 02:49 AM, Chang Xiangzhong wrote:
>>>> tsn_gap_acked is an important state flag in chunk, which indicates if
>>>> the
>>>> chunk has been acked in gap reports before.
>>> Actually, this bit indicates simply that the chunk has been acked.  It
>>> doesn't state whether it's been acked in a gap report or via
>>> cumulative tsn.
>> Thanks for pointing this out. Sorry for not having made that clear.
>>>> SFR-CACC algorithm depends on this
>>>> variable. So set this at the end of each iteration, otherwise the
>>>> SFR-CACC
>>>> algorithm would never be toggled.
>>>>
>>>> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
>>>> ---
>>>>    net/sctp/outqueue.c | 3 ++-
>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>>>> index 1b494fa..bff828c 100644
>>>> --- a/net/sctp/outqueue.c
>>>> +++ b/net/sctp/outqueue.c
>>>> @@ -1396,7 +1396,6 @@ static void sctp_check_transmitted(struct
>>>> sctp_outq *q,
>>>>                 * while DATA was outstanding).
>>>>                 */
>>>>                if (!tchunk->tsn_gap_acked) {
>>>> -                tchunk->tsn_gap_acked = 1;
>>>>                    if (TSN_lt(*highest_new_tsn_in_sack, tsn))
>>>>                        *highest_new_tsn_in_sack = tsn;
>>>>                    bytes_acked += sctp_data_size(tchunk);
>>>> @@ -1460,6 +1459,8 @@ static void sctp_check_transmitted(struct
>>>> sctp_outq *q,
>>>>                     */
>>>>                    list_add_tail(lchunk, &tlist);
>>>>                }
>>>> +
>>>> +            tchunk->tsn_gap_acked = 1;
>>> The current code will set the state if it hasn't been set yet.  Why is
>>> this needed?
>> Because in line 1420 ~ 1440 The SFR-CACC algorithms use tsn_gap_acked.
>> That "if block" would never be triggered because the varaiable's been
>> set. That's why I move the "state changing sentence" to the end of the
>> iteration.
>>> Now there is an issue with tracking highest_new_tsn_in_sack.  The spec
>>> is a little vague on this, but the highest_new_tsn_in_sack only supposed
>>> to track tsns that have not been resent.  If a tsn has been reneged, and
>>> then sent again, it is not considered 'new' thus should not count
>>> toward highest_new_tsn_in_sack.  We currently do not track this right.
>> I'll try to figure this out.
> So the solution that's been proposed before is to move the CACC block up
> and merge it with the !tsn_gap_acked block.  This requires additional
> change though to only mark highest_new_tsn if the chunk has not been
> retransmitted (which you've added in a prior patch).
>
> -vlad
Yeah, I've mixed that up with a prior patch. How was the previous patch? 
Was it approved?
-chang
>>> -vlad
>>>
>>> -vlad
>>>
>>>>            } else {
>>>>                if (tchunk->tsn_gap_acked) {
>>>>                    pr_debug("%s: receiver reneged on data TSN:0x%x\n",
>>>>


  reply	other threads:[~2013-11-23  8:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22  7:49 [PATCH] net: sctp: set chunk->tsn_gap_acked at the end of cycle Chang Xiangzhong
2013-11-22  7:49 ` Chang Xiangzhong
2013-11-22 12:10 ` Neil Horman
2013-11-22 12:10   ` Neil Horman
2013-11-22 14:27 ` Vlad Yasevich
2013-11-22 14:27   ` Vlad Yasevich
2013-11-22 19:24   ` Chang
2013-11-22 19:24     ` Chang
2013-11-22 22:48     ` Vlad Yasevich
2013-11-22 22:48       ` Vlad Yasevich
2013-11-23  8:22       ` Chang [this message]
2013-11-23  8:22         ` Chang
2013-11-23 11:14       ` Chang
2013-11-23 11:14         ` Chang
2013-11-23 19:37         ` Vlad Yasevich
2013-11-23 19:37           ` Vlad Yasevich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529065B3.6060905@gmail.com \
    --to=changxiangzhong@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=vyasevich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.