Reducing delay in port probing for MBIM modems

[Dan Williams]

On Thu, 2014-03-27 at 00:27 -0700, Ben Chan wrote:
> Hi Aleksander,
> 
> I noticed that mm-port-probe.c:wdm_probe_mbim() delays the MBIM probing by
> 3s. What issue does the delay try to address?
> 
> I'm trying to remove/reduce the 3s MBIM probing delay as well as the 2s
> minimum port probe delay (in
> mm-plugin-manager.c:mm_plugin_manager_find_device_support()) on a
> per-device basis. Suppose the generic plugin is used for many MBIM devices,
> is it reasonable to configure these delays via some udev properties?

While I can't comment on the MBIM part, for
mm_plugin_manager_find_device_support() I think the issue is this...

When devices get exposed by the kernel and then udev is variable due to
driver initialization time, udev rules, etc.  So it may well be that one
port shows up 5 seconds before another port, and that probing could
complete within that time.  And then the other port shows up, but we've
already exported the modem to D-Bus and clients have (potentially)
started using it.  So we're left with a dangling port that we should be
using, but can't.

(if it's an AT port then it's easier to handle later.  But if a net or
QMI port shows up long after the AT port has been probed and the modem
created, then we can't use the net port because we may have created a
completely different object for the modem already)

The pathological case: a quick-responding AT port and a net/QMI/MBIM
port that takes a second or two to show up.  If we eliminate the 2s
aggregation delay, it's quite possible that the AT port gets probed and
a Generic modem created before ModemManager is even notified of the
net/QMI/MBIM port by udev.  Then we're stuck with a Generic modem when
it should be a QMI or a Huawei-with-net-device.

Obviously we can and should do better to reduce probing time.  I think a
strategy could be that if we know the minimal useful port setup for a
device, then we should just create and expose the modem with those
ports, and let other ports (NMEA, secondary AT, etc) show up later
because they aren't critical to the modem object.  Some of this is
already implicitly encoded, but we could  make it more explicit.

For example, if we get a qmi_wwan net port, we know we need
one-and-only-one WDM port before the modem is complete.  And we could
mostly assume that whatever WDM port we get will be a QMI port, and when
we have it, modem probing is complete and the modem can be created.  The
same thing might work for MBIM, except there could be multiple WDM and
multiple net ports for these devices in the future.

In addition, specific devices could be tagged with minimal port setup I
suppose, but only for devices we *know* are singular.  I don't mean
specific USB interface tagging, but "Novatel E362 is a known quantity
and we expect only WDM+QMI" type stuff.

Last question: is the delay that's hurting you the port *detection*
(waiting until sufficient ports have been found by udev), or the port
*probing* (determining the protocol each of those ports actually use)?

Thoughts?
Dan