Il giorno ven 21 dic 2018 alle ore 13:33 Bjørn Mork <bj...@mork.no> ha scritto: > > Daniele Palmas <dnl...@gmail.com> writes: > > > This patch fixes qmap header retrieval when modem is configured for > > dl data aggregation. > > > > Signed-off-by: Daniele Palmas <dnl...@gmail.com> > > --- > > Hi Bjørn and all, > > > > I'm facing an issue when using qmi_wwan with modem configured with dl data > > aggregation and qmap multiplexing, e.g. something like > > > > root@L2122:~# qmicli -d /dev/cdc-wdm0 > > --wda-set-data-format=link-layer-protocol=raw-ip,ul-protocol=qmap,dl-protocol=qmap,dl-max-datagrams=20 > > [/dev/cdc-wdm0] Successfully set data format > > QoS flow header: no > > Link layer protocol: 'raw-ip' > > Uplink data aggregation protocol: 'qmap' > > Downlink data aggregation protocol: 'qmap' > > NDP signature: '0' > > Downlink data aggregation max datagrams: '20' > > Downlink data aggregation max size: '16384' > > > > The issue is related to qmap header retrieval in qmimux_rx_fixup: basically > > it seems to me that it is always taken the first qmap header. Maybe the > > patch below should fix this issue. > > > > Note also that, by default, this won't be enough, since also rx_urb_size > > should be changed to the downlink data aggregation max size value: > > currently I'm just modifying the network interface MTU that changes also the > > rx_urb_size. > > > > Not sure if this makes sense, so I thought to share anyway this with you > > for confirmation. > > My personal opinion - take it for that and nothing else: > > Aggregation adds buffer bloat, alignment issues, extra headers with > associated magic handling, and more. It can make sense for some use > cases where each transmission adds significant overhead. The typical > example is radio networks. But I do not think this applies to USB. We > are much better off sending each packet as a separate USB buffer, with a > queue that is just long enough for back-to-back transmission. The > experience with aggregation in NCM/MBIM is not good. > > So I've ignored aggregation in QMI, and will probably continue doing > so. That doesn't mean that I am going to object to you or anyone else > implementing the support if you see a usecase. That's your problem ;-) >
Thanks for the feedback! Regards, Daniele > > > > > Bjørn
