From: Aleksander Morgado <email@example.com> To: "Sergey Ryazanov" <firstname.lastname@example.org>, "Bjørn Mork" <email@example.com> Cc: Stephan Gerhold <firstname.lastname@example.org>, Loic Poulain <email@example.com>, "David S. Miller" <firstname.lastname@example.org>, Jakub Kicinski <email@example.com>, Johannes Berg <firstname.lastname@example.org>, Bjorn Andersson <email@example.com>, Andy Gross <firstname.lastname@example.org>, Vinod Koul <email@example.com>, Rob Herring <firstname.lastname@example.org>, Network Development <email@example.com>, linux-arm-msm <firstname.lastname@example.org>, email@example.com, devicetree <firstname.lastname@example.org>, open list <email@example.com>, firstname.lastname@example.org, ~email@example.com, Jeffrey Hugo <firstname.lastname@example.org> Subject: Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Date: Mon, 26 Jul 2021 10:10:57 +0200 [thread overview] Message-ID: <CAAP7ucLDEoJzwNvWLCWyCNE+kKBDn4aBU-9XT_Uv_yetnX4hemail@example.com> (raw) In-Reply-To: <CAHNKnsQr4Ys8q3Ctru-H=L3ZDwb__2D3E08mMZchDLAs1KetAg@mail.gmail.com> Hey! > > But what if we implement the QMI multiplexing management part in the > kernel? This way the kernel will take care about modem-to-host > communication protocols and interfaces, and provides userspace with a > single WWAN device (possibly with multiple network and network > management interfaces). > > I do not propose to fully implement QMI protocol inside the kernel, > but implement only a mux management part, while passing all other > messages between a "modem" and a userspace software as-is. > > What pros and cons of such a design do you see? > The original GobiNet driver already provided some QMI protocol implementation in the driver itself. In addition to initial device setup as you suggest, it also allowed userspace applications to allocate and release QMI clients for the different services that could be used independently by different processes. Not going to say that was the wrong way to do it, but the implementation is definitely not simple. The decision taken in qmi_wwan to make the driver as simple as possible and leave all the QMI management to userspace was quite an important one; it made the driver extremely simple, leaving all the complexity of managing the protocol to userspace, and while it had some initial drawbacks (e.g. only one process could talk QMI at a time) the userspace tools have evolved to avoid them (e.g. the qmi-proxy). I wrote some time ago about this, maybe it's still relevant today: Blogpost https://sigquit.wordpress.com/2014/06/11/qmiwwan-or-gobinet/, Article in PDF https://aleksander.es/data/Qualcomm%20Gobi%20devices%20on%20Linux.pdf Making the driver talk QMI just for device setup would require the kernel to know how the QMI protocol works, how QMI client allocations and releases are done, how errors are reported, how is the format of the requests and responses involved; it would require the kernel to wait until the QMI protocol endpoint in the modem is capable of returning QMI responses (this could be up to 20 or 30 secs after the device is available in the bus), it would require to have possibly some specific rules on how the QMI clients are managed after a suspend/resume operation. It would also require to sync the access to the CTL service, which is the one running QMI service allocations and releases, so that both kernel and userspace can perform operations with that service at the same time. It would need to know how different QMI capable devices behave, because not all devices support the same services, and some don't even support the WDA service that would be the one needed to setup data aggregation. There is definitely some overlap on what the kernel could do and what userspace could do, and I'd say that we have much more flexibility in userspace to do all this leaving all the complexity out of the kernel driver. ModemManager already provides a unified API to e.g. setup multiplexed data sessions, regardless of what the underlying kernel implementation is (qmi_wwan only, qmi_wwan+rmnet, ipa+rmnet, bam-dmux, cdc_mbim...) . The logic doing all that is extremely complex and possibly full of errors, I would definitely not want to have all that logic in the kernel itself, let the errors be in userspace! Unifying stuff in the kernel is a good idea, but if you ask me, it should be done in a way that is as simple as possible, leaving complexity to userspace, even if that means that userspace still needs to know what type of device we have behind the wwan subsystem, because userspace will anyway need to know all that. -- Aleksander https://aleksander.es
next prev parent reply other threads:[~2021-07-26 8:11 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-19 14:53 [RFC PATCH net-next 0/4] " Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 1/4] dt-bindings: dmaengine: bam_dma: Add remote power collapse mode Stephan Gerhold 2021-07-29 19:36 ` Rob Herring 2021-07-29 19:50 ` Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 2/4] dmaengine: qcom: " Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 3/4] dt-bindings: net: Add schema for Qualcomm BAM-DMUX Stephan Gerhold 2021-07-19 14:53 ` [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Stephan Gerhold 2021-07-19 16:01 ` Loic Poulain 2021-07-22 15:40 ` Stephan Gerhold 2021-07-24 11:25 ` Sergey Ryazanov 2021-07-26 8:10 ` Aleksander Morgado [this message] 2021-07-26 22:40 ` Sergey Ryazanov 2021-07-20 9:10 ` Sergey Ryazanov 2021-07-21 12:17 ` Stephan Gerhold 2021-07-24 10:22 ` Sergey Ryazanov 2021-07-19 15:43 ` [RFC PATCH net-next 0/4] " Jeffrey Hugo 2021-07-19 18:23 ` Stephan Gerhold 2021-07-19 23:13 ` Jeffrey Hugo 2021-07-22 14:51 ` Stephan Gerhold 2021-07-26 14:58 ` Jeffrey Hugo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAAP7ucLDEoJzwNvWLCWyCNE+kKBDn4aBU-9XT_Uv_yetnX4hfirstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).