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

["Gustavo F. Padovan" <padovan@profusion.mobi>]

* Mat Martineau <mathewm@codeaurora.org> [2011-06-30 16:36:01 -0700]:

> 
> 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.

You convinced me, applied! Thanks.

	Gustavo