Hi guys,
On Tue, Apr 19, 2011 at 5:50 PM, Anderson Briglia
<anderson.briglia@xxxxxxxxxxxxx> wrote:
> Hi Marcel,
>
> On Wed, Apr 13, 2011 at 7:20 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
>> Hi Anderson,
>>
>>> >> One thing to consider is that there are a couple of MTU checks along
>>> >> the L2CAP code. The issue which originated this patch is code such as:
>>> >>
>>> >> /* Check outgoing MTU */
>>> >> if (len > pi->omtu) {
>>> >> err = -EMSGSIZE;
>>> >> goto done;
>>> >> }
>>> >>
>>> >> We understood that just letting omtu/imtu values on kernel reflect the
>>> >> current connection MTU settings was the cleanest solution. What do you
>>> >> propose? Bypassing these checks for LE?
>>> >
>>> > this does not look clean to me. And we might have an internal MTU
>>> > variable as part of L2CAP, but the way how it gets set and thus its
>>> > semantic differs clearly between BR/EDR and LE. So shoehorning an
>>> > existing socket option this is clearly a bad idea.
>>>
>>> Sure. What to do then if:
>>>
>>> 1) LE links have MTU (omtu specifically) hard-coded to 23 on kernel.
>>> 2) the kernel rejects sending data longer than omtu.
>>>
>>> (this is the current situation)
>>>
>>> This clearly needs some fix on kernel side, otherwise we can't send
>>> PDUs longer than the LE default MTU (23), *even* if the peer device
>>> supports a bigger MTU.
>>
>> I agree with that. Userspace needs to be able to change the kernel MTU
>> if a different one gets negotiated. That is not the problem. The problem
>> is trying to shoehorn this into an existing (and already declared
>> legacy) socket option.
>>
>>> Suggestions are welcome regarding how to best approach this, without
>>> affecting current BR/EDR MTU semantics.
>>
>> We need to have a socket option that allows us the dynamically change
>> the MTU of a L2CAP link. And right now this option will only be valid if
>> the link is actually an LE link.
>
> Ok, so we have some options IMHO:
>
> a) Do not add a new option in struct l2cap_options because it will
> still be hijacking.
>
> b) Add a new option for LE OMTU in struct l2cap_conninfo. Is it valid?
>
> c) Add a new struct (l2cap_le_options ?) and add a omtu field there.
>
> The problem in c) is that we will have to implement significant
> modifications in userspace and the code should be redundant: we will
> have two options to represent the same value.
Some comments about this a) and b) should be great. LE link
configuration is dependent of this MTU exchange to work properly.
>
> Regards,
>
> Anderson Briglia
>
>>
>> Regards
>>
>> Marcel
>>
>>
>>
>
>
>
> --
> INdT - Instituto Nokia de tecnologia
> +55 2126 1122
> http://techblog.briglia.net
>
--
INdT - Instituto Nokia de tecnologia
+55 2126 1122
http://techblog.briglia.net
--
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
