dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Ryazanov <ryazanov.s.a@gmail.com>
To: Aleksander Morgado <aleksander@aleksander.es>
Cc: "Bjørn Mork" <bjorn@mork.no>,
	"Stephan Gerhold" <stephan@gerhold.net>,
	"Loic Poulain" <loic.poulain@linaro.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Andy Gross" <agross@kernel.org>, "Vinod Koul" <vkoul@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Network Development" <netdev@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	dmaengine@vger.kernel.org,
	devicetree <devicetree@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	phone-devel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht,
	"Jeffrey Hugo" <jeffrey.l.hugo@gmail.com>
Subject: Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver
Date: Tue, 27 Jul 2021 01:40:10 +0300	[thread overview]
Message-ID: <CAHNKnsSeX00+oL7uuKw83fRb0zSJWndQXyQH8PvoKf59mFUYgg@mail.gmail.com> (raw)
In-Reply-To: <CAAP7ucLDEoJzwNvWLCWyCNE+kKBDn4aBU-9XT_Uv_yetnX4h-g@mail.gmail.com>

Hello Aleksander,

On Mon, Jul 26, 2021 at 11:11 AM Aleksander Morgado
<aleksander@aleksander.es> wrote:
>> 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.

Ouch! All these QMI internals are like a can of worms. Each time I
start thinking that I learned something I face another complexity.
Many thanks for your detailed reply and for your blogpost, for me it
was quite helpful for understanding to see a side by side comparison
of approaches!

The argument for keeping drivers minimalistic to keep the system
stable sounds reasonable. But I am still feeling uncomfortable when a
userspace software manages a device at such a low level. Maybe it is a
matter of taste, or maybe I still do not realize the whole complexity.
Anyway, in the context of your clarification, I should be more careful
in the future with calls to implement QMI in the kernel :)

--
Sergey

  reply	other threads:[~2021-07-26 22:40 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
2021-07-26 22:40           ` Sergey Ryazanov [this message]
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=CAHNKnsSeX00+oL7uuKw83fRb0zSJWndQXyQH8PvoKf59mFUYgg@mail.gmail.com \
    --to=ryazanov.s.a@gmail.com \
    --cc=agross@kernel.org \
    --cc=aleksander@aleksander.es \
    --cc=bjorn.andersson@linaro.org \
    --cc=bjorn@mork.no \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=jeffrey.l.hugo@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=phone-devel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=stephan@gerhold.net \
    --cc=vkoul@kernel.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    --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).