* updating unacked_frames counter during retransmission
@ 2011-03-03 6:30 Suraj Sumangala
2011-03-05 0:53 ` Gustavo F. Padovan
0 siblings, 1 reply; 3+ messages in thread
From: Suraj Sumangala @ 2011-03-03 6:30 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth@vger.kernel.org
Hi Gustavo,
I have a question regarding the ERTM implementation.
Should we be incrementing the "l2cap_pinfo.unacked_frames" variable if
we are retransmitting a frame?
Won't this cause the same frame to be accounted twice?
If there are too many retransmissions, will there be a chance that
"unacked_frames" could cross 0xFF and over flow.
Correct me if I have missed anything.
Regards
Suraj
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: updating unacked_frames counter during retransmission
2011-03-03 6:30 updating unacked_frames counter during retransmission Suraj Sumangala
@ 2011-03-05 0:53 ` Gustavo F. Padovan
2011-03-05 8:51 ` Suraj Sumangala
0 siblings, 1 reply; 3+ messages in thread
From: Gustavo F. Padovan @ 2011-03-05 0:53 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth@vger.kernel.org
Hi Suraj,
* Suraj Sumangala <suraj@Atheros.com> [2011-03-03 12:00:35 +0530]:
> Hi Gustavo,
>
> I have a question regarding the ERTM implementation.
>
> Should we be incrementing the "l2cap_pinfo.unacked_frames" variable if
> we are retransmitting a frame?
No, if we are retransmitting a frame that means L2CAP didn't received an ack
for it and we are already accounting it in unacked_frames and there is no need
to increment unacked_frames in this case.
>
> Won't this cause the same frame to be accounted twice?
>
> If there are too many retransmissions, will there be a chance that
> "unacked_frames" could cross 0xFF and over flow.
No, unacked_frames number is limited by the remote transmission window size.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: updating unacked_frames counter during retransmission
2011-03-05 0:53 ` Gustavo F. Padovan
@ 2011-03-05 8:51 ` Suraj Sumangala
0 siblings, 0 replies; 3+ messages in thread
From: Suraj Sumangala @ 2011-03-05 8:51 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi Gustavo,
On 3/5/2011 6:23 AM, Gustavo F. Padovan wrote:
> Hi Suraj,
>
> * Suraj Sumangala<suraj@Atheros.com> [2011-03-03 12:00:35 +0530]:
>
>> Hi Gustavo,
>>
>> I have a question regarding the ERTM implementation.
>>
>> Should we be incrementing the "l2cap_pinfo.unacked_frames" variable if
>> we are retransmitting a frame?
>
> No, if we are retransmitting a frame that means L2CAP didn't received an ack
> for it and we are already accounting it in unacked_frames and there is no need
> to increment unacked_frames in this case.
I think right now we are incrementing the "l2cap_pinfo.unacked_frames"
for retransmission also.
>
>>
>> Won't this cause the same frame to be accounted twice?
>>
>> If there are too many retransmissions, will there be a chance that
>> "unacked_frames" could cross 0xFF and over flow.
>
> No, unacked_frames number is limited by the remote transmission window size.
>
Actually, I am seeing an overflow (crossing the remote transmit window)
issue, when there is retransmission. This was found in older kernel(2.6.35).
So not sure if this is valid in the latest kernel. Will anyway try to
send a patch for the same.
Regards
Suraj
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-03-05 8:51 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-03 6:30 updating unacked_frames counter during retransmission Suraj Sumangala
2011-03-05 0:53 ` Gustavo F. Padovan
2011-03-05 8:51 ` Suraj Sumangala
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).