答复: Instantiating rmnet devices for data ports on QRTR-based modems
Carl Yin(殷张成)
carl.yin at quectel.com
Mon Oct 19 02:09:50 UTC 2020
Hi Aleksander:
> -----邮件原件-----
> 发件人: ModemManager-devel
> [mailto:modemmanager-devel-bounces at lists.freedesktop.org] 代表
> Aleksander Morgado
> 发送时间: Sunday, October 18, 2020 5:05 AM
> 收件人: Carl Yin(殷张成) <carl.yin at quectel.com>
> 抄送: Eric Caruso <ejcaruso at chromium.org>; Naveen Kumar
> <naveen.kumar at quectel.com>; ModemManager (development)
> <modemmanager-devel at lists.freedesktop.org>; Michał Mazur
> <mkm at semihalf.com>; Bjørn Mork <bjorn at mork.no>; Andrew Lassalle
> <andrewlassalle at google.com>; Amit Dayan <amit.dayan at quectel.com>
> 主题: Re: Instantiating rmnet devices for data ports on QRTR-based modems
>
> Hey Carl,
>
> > Some ideas from me.
>
> Thanks for your comments, very much appreciated.
>
> > The discussion is based on QUALCOMM's rmnet driver and his data
> services.
> > We are discussing how porting these software to MM and libqmi.
> > But I think QUALLCOMM's solution is too complex, porting is
> impossible.
> > What we have to do is re-implementation.
> >
> > I seem we have done for "QMI based on QTRT" in libqmi.
> > For QUALCOMM's data services, there are lots of QMI library,
> > and libqmi used a more simply solution. (in fact, if just send QMI,
> > QTRT is also not a good idea)
>
> Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only way to
> handle the communication in certain setups?
[carl.yin] 1. QRTR codes is much complex than direct send QMI message via QMI channel like /dev/cdc-wdm0
And it is not easy to find real hardware device for the QTRT node.
No matter the hardware interface between AP and Qualcomm modem is USB/PCIE/SMD,
(SMD is for QUALCOMM inter-AP, like MDM, APQ,MSM chipset.)
There always have QMI channel can be used to send QMI message.
If use these QMI channel, very few modifies is need apply to libqmi and MM
>
> >
> > So, others part of QUALCOMM's data services and QUALCOMM's
> rmnet drvier, we also can simplify.
> >
>
> I'm all for simplifying :D
>
> > Take rmnet driver for example:
> > QUALCOMM;s rmnet driver consist of two parts.
> > 1. physic netcard part, name as
> rmnet_usb.c/rmnet_mhi.c/rmnet_ipa.c,, depend on the hardware interface
> used.
> > this driver response for transfer QMAP packet to modem.
> > 2. virtual nectar part, name as rmnet_data.c, this driver response for:
> rx IP packets from tcp/ip stack, and add QMAP header to IP packet, and sent to
> rmnet physic driver.
> >
>
> Ok, understood.
>
> > 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?
[carl.yin] this will be make driver simply, several rmnet hardware interface driver, and only one rmnet data/qmap driver.
And we can use tcpdump -I rmnet_usb0 to capture QMAP packets, and use tcpdump -i rmnet_data0 to catch IP packets.
And if we have two network interface, then can effective use SMP by 'echo cpu_mask > /sys/class/net/<iface>/queues/rx-0/rps_cpus '
>
> > 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?
>
> > 6. MM want to setup data call on PDN-x. MM send muxid-X to rmnet
> physic driver, rmnet physic driver tell rmnet data driver to create rmnet_dataX.
> >
>
> This logic you're suggesting, except for step 5 I think, is what we already had in
> mind more or less. I think we could have that done by ModemManager, and
> connection managers like NetworkManager will get that working automatically,
> but now I also fear that if we change the default QMI modem behavior w.r.t.
> which is the connected network interface, we may be breaking user setups out
> there that rely on fixed interface names (e.g. for iptables rules).
>
> > rmnet_dataX is not a good name, there may be rment_usb0,
> rment_mhi0 exist at the same time, so can named as rment_usb0_X.
>
> In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And if you
> have 5 different modems, each of them instantiating muxed virtual interfaces,
> they'll just get assigned sequential interface names, without any reference in the
> interface name to which physical interface they're mapped to. I don't think the
> name of the interface matters much at this point, as long as we can know which
> virtual interface maps to which physical interface.
>
> E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs contents
> pointing to the physical interface:
> # ls -ltr /sys/class/net/qmimux0/lower_wwan0
> lrwxrwxrwx 1 root root 0 Oct 17 20:52
> /sys/class/net/qmimux0/lower_wwan0 ->
> ../../../pci0000:00/0000:00:16.0/usb1/1-1/1-1.2/1-1.2:1.8/net/wwan0
>
> And it adds a "upper_qmimux0" file in the physical interface sysfs pointing to the
> virtual device:
> # ls -ltr /sys/class/net/wwan0/upper_qmimux0
> lrwxrwxrwx 1 root root 0 Oct 17 20:53
> /sys/class/net/wwan0/upper_qmimux0 ->
> ../../../../../../../../virtual/net/qmimux0
>
> As long as we have this kind of relationship between the virtual and physical
> interfaces, we're good to go, regardless of the actual naming of the interface.
[carl.yin] developer can find the relationship of wwanX and qmimuxX.
But for the end customers, maybe it is difficult, maybe he want to setup data call on PDN-x on modem y.
It will be Very intuitive if we can make PDN-x to muxid-X to rmnet_modemY_X.
>
> It is true, though, that with the current qmi_wwan logic we cannot force
> Qualcomm's relationship between mux ID and the name of the interface being
> ID-1, because the qmimux names are given sequentially as they're allocated. Not
> a big deal, though.
>
> --
> Aleksander
> https://aleksander.es
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
More information about the ModemManager-devel
mailing list