mbim-proxy listening to systemd suspend/resume events

Aleksander Morgado aleksander at aleksander.es
Fri Sep 18 17:30:15 UTC 2020


Hey,

> > > From a device point of view, the application asks for notifications, and
> > > then doesn't read them.
> > > It is forced to buffer them, and the buffer is limited.
> >
> > The device knows the USB connection is suspended.  It should not attempt
> > to send any USB data when this happens.  This is the same on the host
> > side.  We kill URBs before suspending.
> >
> > There is no obligation to buffer everything on the device.  That would
> > not scale at all. The device can and should drop anything it cannot
> > deliver in a timely manner, whether that is a notification for the host
> > or incoming data packets from the network.
> >
>
> Yes, I do agree that the device firmware should be robust enough to
> handle this, and this has also been my suggestion when I learned about
> this issue. The device should be able to handle this nicely, not rely
> on the host requiring the MBIM session close.
>
> As with MM's own suspend/resume logic, it's really optional at build
> time, and if there are systems that require to keep open TCP sessions
> during suspend, this can be disabled. Don't take me wrong, I totally
> understand your point regarding the open TCP sessions, but if we were
> to support that I would first focus on doing it at MM level in a
> generic way.

I've changed my mind a bit over the past days (thanks Bjørn for your
point of view!), and now I think that we should probably try to handle
the suspend/resume logic more gracefully in ModemManager. Whenever
possible, we should try to keep the ongoing connection up and
therefore not explicitly disconnect and disable the modem. I have no
idea how clean that would be for all usecases that we need to consider
though; e.g. the modem may be externally powered and therefore kept
on, or the modem may also get suspended or even powered off... I'll
try to work on this in this next MM dev cycle.

So, I don't think we should be merging this MR as it is for the time
being. I'd like to investigate a bit more about the MM use case, and
then suggest the way forward for libmbim again here in the mailing
list.

-- 
Aleksander
https://aleksander.es


More information about the libmbim-devel mailing list