Re: [RFC] No multiplexing by default in MM 1.18
On Wed, Aug 04, 2021 at 09:37:04AM +0200, Aleksander Morgado wrote:
> 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.rs...@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?
Hi Aleksander,
yes, that's Linux 5.2 and now also Linux 4.19.203 and Linux 4.14.244.
> 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.
According to a quick check at git.kernel.org Daniele's
"net: usb: qmi_wwan: allow qmimux add/del with master up" patch was
applied to all relevant longterm kernels (4.14, 4.19, 5.4 and 5.10).
Regards,
Reinhard
Re: [RFC] No multiplexing by default in MM 1.18
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.rs...@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
Re: [RFC] No multiplexing by default in MM 1.18
Hi Aleksander, hi Daniele,
On Tue, Aug 03, 2021 at 12:23:37PM +0200, Daniele Palmas wrote:
> Hi Aleksander,
>
> Il giorno lun 2 ago 2021 alle ore 16:41 Aleksander Morgado <
> aleksan...@aleksander.es> ha scritto:
>
> > Hey all,
> >
> > 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.rs...@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.
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?
Regards,
Reinhard
Re: [RFC] No multiplexing by default in MM 1.18
Hi Aleksander, Il giorno lun 2 ago 2021 alle ore 16:41 Aleksander Morgado < aleksan...@aleksander.es> ha scritto: > Hey all, > > 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. Thanks, Daniele > I've also updated the daemon to have a "--test-multiplex-requested" > option, so that if given, the default would be back to attempt to > enable multiplexing whenever possible. > > The main reason for this decision is that the network interface that > gets connected if multiplexing is enabled would change between 1.16 > and 1.18, because with multiplexing we're connecting an ephemeral > network link that we have created during runtime (e.g. for a QMI > modem that had a connected net interface named wwan0 in 1.16, the > connected net interface in 1.18 would be named qmapmux0.0 instead). > > This connected net interface name change wasn't an issue for > NetworkManager or standard distributions, but it would have been a > major change for every other custom system using ModemManager, if e.g. > custom firewall or routing rules were configured based on the network > interface name and such. I think we should provide more information > about the feature to system integrators, and give some more time for > the feature to be used and tested, before discussing again whether it > should be the default or not in 1.20. > > The MR that includes the changes to update the multiplexing default is > this one, including some other related fixes: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/598 > > Comments welcome! > > -- > Aleksander > https://aleksander.es >
[RFC] No multiplexing by default in MM 1.18
Hey all, 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've also updated the daemon to have a "--test-multiplex-requested" option, so that if given, the default would be back to attempt to enable multiplexing whenever possible. The main reason for this decision is that the network interface that gets connected if multiplexing is enabled would change between 1.16 and 1.18, because with multiplexing we're connecting an ephemeral network link that we have created during runtime (e.g. for a QMI modem that had a connected net interface named wwan0 in 1.16, the connected net interface in 1.18 would be named qmapmux0.0 instead). This connected net interface name change wasn't an issue for NetworkManager or standard distributions, but it would have been a major change for every other custom system using ModemManager, if e.g. custom firewall or routing rules were configured based on the network interface name and such. I think we should provide more information about the feature to system integrators, and give some more time for the feature to be used and tested, before discussing again whether it should be the default or not in 1.20. The MR that includes the changes to update the multiplexing default is this one, including some other related fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/598 Comments welcome! -- Aleksander https://aleksander.es
