<div dir="ltr"><div dir="ltr"><div>Being able to dynamically create links without bringing down the master interface is required in my opinion since we might not know how many we are going to need at the time the first link is created.</div><div><br></div><div><div dir="ltr">Pre-creating 4 links for qmi_wwan seems like a good compromise.</div><div></div></div><div dir="ltr"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 16, 2021 at 12:52 AM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey,<br>
<br>
> > Ok, I've just realized this cannot be done. Creating new links<br>
> > *requires* the interface to be dow<br>
><br>
> Ouch. Never noticed that before.  Tells you how much I've been using<br>
> this.... Doesn't look quite right to me.<br>
><br>
> I believe the part we wanted to protect is the modification of the<br>
> master interface.  But there is no reason we couldn't add and/or delete<br>
> links 2+ with master running.  Actually, I am not sure there is any<br>
> reason at all here?  This seems to be just accidentally copied from the<br>
> raw-ip code.  But there we change the header_ops etc on master, so it<br>
> makes sense. We don't do anything like that for muxing - the master is<br>
> left as-is.  So why not just add/del links on the fly without taking<br>
> down master?<br>
><br>
> A bit late to fix that now, I guess.  At least for your immediate needs.<br>
> But I believe we could loosen up the restrictions without breaking any<br>
> userspace expectations. So it's tempting to fix it in any case.  If<br>
> anyone cares?<br>
><br>
<br>
This limitation doesn't seem to exist when using rmnet.<br>
<br>
$ sudo qmicli -d /dev/cdc-wdm0 --set-expected-data-format=qmap-pass-through<br>
[/dev/cdc-wdm0] expected data format set to: qmap-pass-through<br>
$ sudo ip link set up dev wwp0s20f0u8u2i4<br>
$ sudo qmicli -d /dev/cdc-wdm0<br>
--link-add="mux-id=1,iface=wwp0s20f0u8u2i4,prefix=qmapmux"<br>
[/dev/cdc-wdm0] link successfully added:<br>
  iface name: qmapmux0<br>
  mux-id:     1<br>
<br>
Until now I was hoping to keep both qmi_wwan-based and rmnet-based<br>
logic in sync everywhere, with more or less luck, but this specific<br>
issue is too big of a change I think. Requiring a new ModemManager API<br>
to pre-create N links before they're used, when it's not strictly<br>
required with rmnet, is a bad limitation. Right now, I'm thinking that<br>
I could limit in ModemManager the amount of different links to use<br>
when using qmi_wwan to a sane default, e.g. 3 or 4? and pre-create<br>
those links before bringing up the master interface. And for rmnet,<br>
keep the logic as it is and only create the link when needed. What do<br>
you think?<br>
<br>
At the end, the way I'm working on it right now, the qmi_wwan<br>
add_mux/del_mux logic in MM will be used only for kernels that don't<br>
support the pass-through flag yet.<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</blockquote></div>