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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux