[RFC] No multiplexing by default in MM 1.18

[Aleksander Morgado]

Hey Reinhard,

> > > I've been testing with all my modems for the next 1.18 release, and
> > > for the QMI and MBIM ones I've done tests with and without
> > > multiplexing support (i.e. connecting normally as we did until now,
> > > and also connecting with multiplexing enabled).
> > >
> > > All the QMI modems I have tested with have worked fine. If QMAP wasn't
> > > supported by the modem and we were requesting multiplexing, it would
> > > automatically just fallback to no multiplexing (802.3 or plain
> > > raw-ip), and that was it.
> > >
> > > Most of the MBIM modems I have tested with have worked fine as well,
> > > with the exception of the Netgear AC340U, which would reply with
> > > "InvalidParameters" if we were attempting to connect any session with
> > > id != 0. All the other modems have been able to correctly setup
> > > multiplexing when requested without issues.
> > >
> > > Even if the tests have been quite satisfactory overall (I've tested
> > > >60 different modems in the past month), I think that for 1.18 we
> > > should not enable multiplexing by default (except for IPA), and still
> > > leave it as a requirement from the user at connect time. So, if the
> > > user wants to setup a connection with multiplexing enabled, it should
> > > pass either "multiplex=requested" or "multiplex=required" in the
> > > connection settings explicitly
> > >
> > >
> > I think it makes sense.
> >
>
> I too think it makes sense to not enable multiplexing by default at
> this point in time.
>
> Since commit 44f82312fe91 ("qmi_wwan: add network device usage statistics
> for qmimux devices") of my "qmi_wwan: fix QMAP handling" series
> https://lore.kernel.org/netdev/cover.1560287477.git.rspmn@arcor.de
> was not backported to 4.14.x and 4.19.x longterm kernels by Sasha Levin's
> "AUTOSEL" patches this would introduce a regression for users of those
> kernel versions with MM 1.18 otherwise.
>

Oh, thanks for pointing that out. I always try to test with the latest
available kernel in Arch, and not so much with older kernels, but it's
definitely something to take into account. That patch was included in
Linux 5.2 for what I can tell, right?

Note that if rmnet is available, the ModemManager logic currently
defaults to using rmnet instead of qmi_wwan add_mux/del_mux, which has
some limitations in some older kernel versions as well.

> The reason for this is probably that it violates the "It cannot be bigger
> than 100 lines, with context." rule from
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html .
>
> Perhaps it would make sense to split up the patch into two parts if required
> to meet formal criteria and submit it for 4.14.y and 4.19.y kernels so
> that users don't have to resort to building qmi_wwan.ko from out-of-tree
> drivers like https://forum.sierrawireless.com/t/rc7620-and-linux-driver/24308
> to avoid the regression?
>

Maybe the inclusion in the stable kernels can be explicitly requested
as they are? If the patches are fixing real issues I guess there
should not be any problem to integrate them in the stable trees, and
splitting the patches in smaller ones just for the sake of being less
than N lines looks a waste of time?

-- 
Aleksander
https://aleksander.es