答复: Instantiating rmnet devices for data ports on QRTR-based modems

[Carl Yin(殷张成)]

Hi All:
	Some ideas from me.
	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)

	So, others part of QUALCOMM's data services and  QUALCOMM's rmnet drvier, we also can simplify.

	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.

	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
	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.
	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.

	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.



Thanks & Best Regards!

殷张成  Carl yin| Software System Department Engineer | Quectel Wireless Solutions 

Mobile: +86-138 0569 2573 |  Email : carl.yin at quectel.com  |  Tel: +86-551-65869386-8666
Website: www.quectel.com  | QQ: 7712269  | Wechat: 13805692573

Building 1-C, China Speech Valley Area A, 3335 Xiyou Road, High-tech Zone, Hefei, Anhui 230088, China
安徽省合肥市高新区习友路3335号中国（合肥）国际智能语音产业园A区1号中试楼 230088
HQ: Building 5, Shanghai Business Park Phase III (Area B), No.1016 Tianlin Road, Minhang District, Shanghai 200233, China
总部：上海市闵行区田林路1016号科技绿洲3期（B区）5号楼  200233




> -----邮件原件-----
> 发件人: ModemManager-devel
> [mailto:modemmanager-devel-bounces at lists.freedesktop.org] 代表
> Aleksander Morgado
> 发送时间: Saturday, October 17, 2020 5:20 AM
> 收件人: Eric Caruso <ejcaruso at chromium.org>
> 抄送: 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>
> 主题: Re: Instantiating rmnet devices for data ports on QRTR-based
> modems
> 
> Hey,
> 
> > > > And an additional question I have; what if we start using QMAP
> > > > also for qmi_wwan based modems that support it? I think it would
> > > > be very similar to your current needs with QRTR/IPA, right? See
> > > > https://lists.freedesktop.org/archives/libqmi-devel/2018-July/0029
> > > > 35.html Maybe we can setup a common API in libqmi that brings up
> > > > the muxed network interfaces for both cases in a common way?
> > >
> > > Yes, that exact thought stroke me as well while skimming through
> > > this discussion. It would be nice if the API could abstract away the
> > > differences wrt adding network devices etc, and just present a
> > > common muxing API.
> >
> > I haven't personally dealt with QMAP so I'm not really sure what's
> > going on there. The linked discussion does suggest a similar
> > architecture of one "real" net interface (wwan0 for QMAP, rmnet_ipa0
> > for QRTR/IPA) over which several "virtual" net ports are overlaid
> > (qmimuxN for QMAP, rmnet_dataN for QRTR/IPA).
> >
> > Neither case would deal with QMI directly outside of the Bind Mux Data
> > Port message though, as far as I can tell. So I'm not sure if this is
> > an argument for keeping it in libqmi or not.
> >
> 
> At this point, I start to prefer the idea of keeping it in libqmi, but the logic
> should not be automatic on QmiDevice open. libqmi could provide a
> common method to add/delete the muxed interfaces, and that method
> would be implemented differently depending on what kernel driver is in
> use. Then, upper layers like MM or other programs using qmicli could
> trigger the instantiation of the virtual net devices as part of the connection
> attempt procedure.
> 
> --
> Aleksander
> https://aleksander.es
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel