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.
Regards,
Anderson Briglia
>
> Regards
>
> Marcel
>
>
>
--
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
