Maximum QMI request size?

[Bjørn Mork]

Aleksander Morgado <aleksander at lanedo.com> writes:

>>> The theoretical maximum size is a little over 64k, since the length field
>>> is 16 bits.  I think it would make sense to use that as a maximum in the
>>> kernel.
>> 
>> Yes, maybe.  It just feels a bit wrong to allocate 64k buffers if no
>> message can exceed 1.5k.  And I have not yet seen any larger message in
>> any direction.
>> 
>> I am deliberately ignoring the possibility of sending multiple QMI
>> messages in a single QMUX.  The device won't do that, and I have not
>> observed anything like that from the Windows driver either.
>> 
>> 
>
> The weirdest TLV I've seen for now related to length is the "Preferred
> Roaming List" (0x13) in the "DMS/Activate Manual" message. This TLV
> allows a buffer of binary data of up to 16384 bytes, *but* the buffer
> may be split into different segments of shorter sizes and sent over
> multiple QMI messages. It doesn't answer any question I think :-)

Very useful!  I believe the fact that this is documented as max 16384
*and* have fragmentation support indicates that the maximum QMI message
is smaller than 16384.

Note that this fragmented TLV with sequence numbers is similar to the
PDS XTRA database upload TLV, which does not have a documented maximum
except that the total size must fit in an u16 field.  The current
database is 60831 bytes, so the real life value is getting close to this.

I will run a couple of tests on these requests with a large buffer, to
see when I get "segment too long" errors with the devices I have. 


Bjørn