Part 2 article on l2cat and optimizing data throughput

[potto216]

Hi All, I posted the second article in the series on transferring files with BlueR's l2cat at https://medium.com/@potto_94870/async-rust-bluetooth-plumbing-where-the-throughput-goes-d2cf21430a90. The article should be accessible by anyone without a Medium account. I appreciate suggestions and corrections.

[Vudentz]

Hi All, I posted the second article in the series on transferring files with BlueR's l2cat at https://medium.com/@potto_94870/async-rust-bluetooth-plumbing-where-the-throughput-goes-d2cf21430a90. The article should be accessible by anyone without a Medium account. I appreciate suggestions and corrections.

Note that the credits given are no longer based on MTU / SDU since:

commit ce60b9231b66710b6ee24042ded26efee120ecfc
Author: Sebastian Urban <surban@surban.net>
Date:   Wed May 1 12:08:58 2024 +0200

    Bluetooth: compute LE flow credits based on recvbuf space
    
    Previously LE flow credits were returned to the
    sender even if the socket's receive buffer was
    full. This meant that no back-pressure
    was applied to the sender, thus it continued to
    send data, resulting in data loss without any
    error being reported. Furthermore, the amount
    of credits was essentially fixed to a small
    amount, leading to reduced performance.
    
    This is fixed by computing the number of returned
    LE flow credits based on the estimated available
    space in the receive buffer of an L2CAP socket.
    Consequently, if the receive buffer is full, no
    credits are returned until the buffer is read and
    thus cleared by user-space.
    
    Since the computation of available receive buffer
    space can only be performed approximately (due to
    sk_buff overhead) and the receive buffer size may
    be changed by user-space after flow credits have
    been sent, superfluous received data is temporary
    stored within l2cap_pinfo. This is necessary
    because Bluetooth LE provides no retransmission
    mechanism once the data has been acked by the
    physical layer.
    
    If receive buffer space estimation is not possible
    at the moment, we fall back to providing credits
    for one full packet as before. This is currently
    the case during connection setup, when MPS is not
    yet available.
    
    Fixes: b1c325c23d75 ("Bluetooth: Implement returning of LE L2CAP credits")
    Signed-off-by: Sebastian Urban <surban@surban.net>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

[potto216]

@Vudentz thanks for the info. How do I find the commit? I tried bluez/bluez@ce60b92 but GitHub said it wasn't valid and several searches on the keywords didn't find anything. I'll make a note of this in the article.