On Fri, 1 Jul 2011, Gustavo F. Padovan wrote:
* Mat Martineau <mathewm@xxxxxxxxxxxxxx> [2011-06-30 16:36:01 -0700]:
Hi Gustavo -
On Thu, 30 Jun 2011, Gustavo F. Padovan wrote:
* Mat Martineau <mathewm@xxxxxxxxxxxxxx> [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.
Thanks for applying this! Have you had a chance to consider the other
local busy changes for recv_cb?
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
