Instantiating rmnet devices for data ports on QRTR-based modems

[Aleksander Morgado]

Hey,

> > >         So the process can next:
> > >         1. rmnet physic driver probe, create netcard rmnet_usb0/rmnet_mhi0/rmnet_ipa0, and call register_rmnet_data
> > >         2. rmnet data driver create rmnet_data0
> >
> > Are you suggesting that there is always a virtual network interface
> > created for the physical network interface? In terms of qmi_wwan, are
> > you suggesting a virtual qmimux0 is always created when the physical
> > wwan0 interface is exposed? What would be the benefit of doing that?
> >
>
> One of the benefits is dl throughput for high-cat modems, since
> enabling data aggregation is mandatory to get the most out of the
> modem.
>

That's a good point.

> > >         3. MM query qmap-version, ep-type, iface-id, dll_data_aggregation_max_size from rmnet physic driver
> > >         4. MM send QMIWDS_ADMIN_SET_DATA_FORMAT_REQ to modem.
> > >         5. MM get ul_data_aggregation_max_size from QMIWDS_ADMIN_SET_DATA_FORMAT_RESP, and send to rmnet physic driver.
> >
> > @Bjørn Mork @Daniele Palmas is that step 5 something we're not
> > currently doing and we may need to do? Does the physical wwan
> > interface truly need to know the ul_data_aggregation_max_size?
> >
>
> I can't find this WDS request, or do you mean QMI_WDA_SET_DATA_FORMAT?

Yes, that's what he refers to.

> Anyway, the driver is not dealing with ul values: so far I did not
> receive complaints on upload performance, even with high-cat modems,
> so I'm not sure this is something that should be fixed at the moment.
> I'm more concerned about the dl aggregation, whose setting is still a
> manual process.
>

Carl, could you elaborate on why the kernel driver would need to know
about ul_data_aggregation_max_size? What is the downside of not
implementing it?

> By the way, not strictly related to this thread, but there is a very
> good effort ongoing for upstreaming mhi driver, mainly targeted on
> SDX55, see for example
> https://patchwork.kernel.org/project/linux-arm-msm/patch/1602258664-9980-1-git-send-email-loic.poulain@linaro.org/
> and https://www.spinics.net/lists/netdev/msg692557.html
>
> The uci driver is still missing, but I think it will be just a matter
> of time: the interesting part is that with uci a char qmi device is
> exposed that, according to my current tests, is behaving at the high
> level just like the cdc-wdm device.

I believe Carl is already testing a setup like that one as well.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/254

-- 
Aleksander
https://aleksander.es