From: Jerri Lipp <JerriLipp@proton.me>
To: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Cc: "johan+linaro@kernel.org" <johan+linaro@kernel.org>
Subject: chasing a throughput issue the cdc_acm driver does NOT have
Date: Mon, 22 Apr 2024 18:23:33 +0000 [thread overview]
Message-ID: <H7wSaXg5qDFzZjLSmSYVmFzB6iBG6XDCISeX4sGiZ-UIFSE0uOKPa1EOKYEiogez9xwcnQbYQFumiKFA733_05w9246qL1Hg_PnlARP2wWg=@proton.me> (raw)
Hi,
I'm working on a project that talks to an STM32 MCU via a Full-Speed USB
CDC_ACM link, which binds to the cdc_acm driver. I initially used dd to
measure throughput and all was well. Then I switched to libusb and found that
throughput dropped by 50%. I traced the root cause to a something the cdc_acm
driver does, which my libusb code didn't. But I don't understand why this
makes a difference and was hoping someone on the list would be kind enough to
educate me.
In my test, the traffic was just one way: Host->Device. So I did not bother
to intiate any IN transfers. It turns out that even without any IN traffic,
the absence of any outstanding IN transfers drops the OUT throughput by half.
Wireshark showed me that using dd to send data to the device actually does
result in some IN transfers showing up at the very start of the trace, though
never completing.
I think (could be wrong) I traced these IN transfers to their origin in cdc-acm.c.
there's a call to acm_submit_read_urb in acm_port_activate():
"""
retval = acm_submit_read_urbs(acm, GFP_KERNEL);
if (retval)
goto error_submit_read_urbs;
usb_autopm_put_interface(acm->control);
"""
which I read as initiating some read urbs as soon as comms start, exactly what I saw.
I blamed this line back to 2011, when it showed up after an unrelated refactor
in 088c64f81284. Back then, this call to acm_submit_read_urbs()
lived inside acm_tty_open().
I've looked at the "Complete USB" book, the libusb mailing list and google. I could
not find any explanation of why this behavior is needed - why do pending IN transfers
have such an effect on throughput when there is zero IN traffic from the device?
Your wisdom much appreciated,
Jerri
CC @jhovold (author of 088c64f81284, apologies if that's not ok)
reply other threads:[~2024-04-22 18:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='H7wSaXg5qDFzZjLSmSYVmFzB6iBG6XDCISeX4sGiZ-UIFSE0uOKPa1EOKYEiogez9xwcnQbYQFumiKFA733_05w9246qL1Hg_PnlARP2wWg=@proton.me' \
--to=jerrilipp@proton.me \
--cc=johan+linaro@kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).