Re: [PATCH 1/6] Bluetooth: Check earlier for L2CAP ERTM frames to drop

[Mat Martineau <mathewm@codeaurora.org>]

Hi Gustavo -

On Thu, 30 Jun 2011, Gustavo F. Padovan wrote:

> * Mat Martineau <mathewm@codeaurora.org> [2011-06-29 14:35:19 -0700]:
>
>> Even when the received tx_seq is expected, the frame still needs to be
>> dropped if the TX window is exceeded or the receiver is in the local
>> busy state.
>
> The check doesn't mean that TX window is exceeded, it means that we have an
> invalid tx_seq and connection should be closed. I don't see the point in
> moving the expected check to after this one.
> About the local busy check. Is it worth to drop expected frames when on local
> busy? What are the advantages/disadvantages? Drop will trigger SREJ while
> Store will press the buffer. Do you have measures to prove this?


It's possible for expected_tx_seq to be invalid if the tx window is 
full.  Therefore it is important to check for an invalid tx_seq before 
checking if it is expected.


Dropping frames during local busy is a good idea because:

  * Queuing frames during local busy ignores the receive buffer limits 
requested by the application with SO_RCVBUF.  This problem gets worse 
with extended window sizes, where the busy_q could be quite large
  * ERTM senders are not supposed to send frames during local busy 
anyway
  * The spec allows for packets to be dropped in local busy (look for 
"StoreOrIgnore")

It's the memory that's most important, though. Dropping all incoming 
iframes during local busy is a simple way to keep data buffer size 
bounded while still allowing for larger tx windows.

If the application can't keep up with the data rate and is triggering 
local busy, throughput isn't going to be improved significatnly by 
queuing those frames during local busy.

--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum