Re: [PATCH 2/2] Bluetooth: Add ability to force local busy condition on L2CAP ERTM

[Mat Martineau <mathewm@codeaurora.org>]

On Wed, 9 Nov 2011, Marcel Holtmann wrote:

> Hi Syzmon,
>
>>>>> NACK on this. I don't wanna move code with the specific purpose of pass a PTS
>>>>> test into the tree. This kinda of thing can survive outside of the tree.
>>>>
>>>> actually it can not life outside the tree. We need to be able to pass
>>>> the PTS test cases with an upstream source.
>>>>
>>>> However instead of hacking this in, what is the actual test case details
>>>> here that we need to have support for?
>>>
>>> ERTM will send an RNR when the socket receive buffer fills up.  For
>>> this test case, it works to just set the SO_RCVBUF sockopt to
>>> a small enough value that the recv buffer fills before the transmit
>>> window does - no kernel changes required.
>>
>> @Marcel
>> This test case is to "Verify the IUT will send an S-Frame [RNR] when it detects a Local Busy condition."
>>
>> "Pass verdict:
>> - ALT 1: The IUT immediately sends an S-Frame with function RNR after the Local
>> Busy condition is set by the Upper Tester.
>> - ALT 2: The IUT sends an S-Frame with function RNR after receiving I-Frame(s) from
>> the Tester when the Local Busy condition is set by the Upper Tester."
>>
>>
>> I was trying to pass ALT2 with Mat's suggestions but couldn't trigger local busy.
>> Minimum possible value for SO_RCVBUF (at least here on 3.0 kernel) is 2224 bytes and this is
>> still too high to allow PTS to trigger local busy (PTS tries to send txwin i-frames with 4 bytes of
>> data only).
>> [If it would possible to force PTS to send larger i-frames than it should work as well but I wasn't
>> able to find any option that would do that... please correct me if it is possible]
>>
>> With forcing local busy on channels it is possible to pass ALT1 scenario: PTS ask IUT to enter
>> local busy condition and just waits for RNR to be send.
>>
>> @Gustavo
>> If you prefer not to temper with normal code path I could just get rid of force_local_busy variable
>> and not hold channels in local busy state. This should be enough to pass test.
>
> so I like the idea to make this work with standard socket options. That
> is how we should be doing this. So lets figure out on how to make Mat's
> suggestion work for us.

Even with only 4 bytes of data, the buffer size limits also include 
sk_buff overhead of several hundred bytes per packet, so 2224 is small 
enough.  You also have to slow down (or stop) the reader of the data 
in userspace - otherwise, the reader pulls data out of the socket 
rcvbuf as soon as it arrives, and the buffer stays nearly empty.

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