[Question] How should mctp‑usb handle TX URB timeouts to recover when the device stops responding and recovers after some time?

[suresh-vijay-msft]

Hi Jeremy,

Quick question on the MCTP-over-USB driver: what’s the mechanism by which a submitted URB gets cancelled, leading to a stopped network queue being woken up?

In the upstream implementation (mainline mctp-usb.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/mctp/mctp-usb.c), it looks like the queue is woken in mctp_usb_out_complete() after a successful URB completion. This makes me wonder whether delayed/non-successful completions can keep the TX queue stopped long enough for the skb backlog to hit limits and surface as ENOBUFS to userspace.

Do the multi‑URB enhancements in this branch address that behavior?

https://github.com/CodeConstruct/linux/blob/test/mctp-usb/drivers/net/mctp/mctp-usb.c

If yes, what’s the current line of sight / plan for upstreaming those changes?

Thanks,
Suresh

[jk-ozlabs]

Yes, an error completion will not re-start the TX queues; at that point, we don't have any indication when (or if) we are able to resume TX to the device.

The upstream driver is pretty simple, and is conservative with URB queuing. If you have conditions where the hardware is stopping and then recovering, I would like to see the patterns of completions that you're seeing over that span to determine what the recovery mode should be.

The mutli-urb implementation does handle this, yes. I don't have any specific timeline for upstreaming (I have a couple of improvements in mind still), but any results of your testing would be helpful for that process.