From: Greg KH <gregkh@linuxfoundation.org>
To: Jayant Chowdhary <jchowdhary@google.com>
Cc: corbet@lwn.net, laurent.pinchart@ideasonboard.com,
dan.scally@ideasonboard.com, kieran.bingham@ideasonboard.com,
linux-usb@vger.kernel.org, inux-doc@vger.kernel.org,
etalvala@google.com, arakesh@google.com
Subject: Re: uvc gadget: Making upper bound of number of usb requests allocated configurable through configfs
Date: Sun, 8 Oct 2023 07:45:37 +0200 [thread overview]
Message-ID: <2023100834-statistic-richly-49ef@gregkh> (raw)
In-Reply-To: <edad1597-48da-49d2-a089-da2487cac889@google.com>
On Fri, Oct 06, 2023 at 03:03:56PM -0700, Jayant Chowdhary wrote:
> Hi Everyone,
>
> We had been seeing the UVC gadget driver receive isoc errors while
> sending packets to the usb endpoint - resulting in glitches being shown
> on linux hosts. My colleague Avichal Rakesh and others had a very
> enlightening discussion at
> https://lore.kernel.org/linux-usb/8741b7cb-54ec-410b-caf5-697f81e8ad64@google.com/T/
>
>
> The conclusion that we came to was : usb requests with actual uvc frame
> data were missing their scheduled uframes in the usb controller. As a
> mitigation, we started sending 0 length usb requests when there was no
> uvc frame buffer available to get data from. Even with this mitigation,
> we are seeing glitches - albeit at a lower frequency.
>
> After some investigation, it is seen that we’re getting isoc errors when
> the worker thread serving video_pump() work items, doesn’t get scheduled
> for longer periods of time - than usual - in most cases > 6ms.
> This is close enough to the 8ms limit that we have when the number of usb
> requests in the queue is 64 (since we have a 125us uframe period). In order
> to tolerate the scheduling delays better, it helps to increase the number of
> usb requests in the queue . In that case, we have more 0 length requests
> given to the udc driver - and as a result we can wait longer for uvc
> frames with valid data to get processed by video_pump(). I’m attaching a
> patch which lets one configure the upper bound on the number of usb
> requests allocated through configfs. Please let me know your thoughts.
> I can formalize the patch if it looks okay.
Why do you want to limit the upper bound? Why not just not submit so
many requests from userspace as you control that, right?
>
> Thank you
>
> Jayant
>
> ---
> .../ABI/testing/configfs-usb-gadget-uvc | 2 ++
> Documentation/usb/gadget-testing.rst | 21 ++++++++++++-------
> drivers/usb/gadget/function/f_uvc.c | 4 +++-
> drivers/usb/gadget/function/u_uvc.h | 1 +
> drivers/usb/gadget/function/uvc.h | 3 +++
> drivers/usb/gadget/function/uvc_configfs.c | 2 ++
> drivers/usb/gadget/function/uvc_queue.c | 5 ++++-
> 7 files changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> index 4feb692c4c1d..9bc58440e1b7 100644
> --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> @@ -7,6 +7,8 @@ Description: UVC function directory
> streaming_maxburst 0..15 (ss only)
> streaming_maxpacket 1..1023 (fs), 1..3072 (hs/ss)
> streaming_interval 1..16
> + streaming_max_usb_requests 64..256
> +
> function_name string [32]
> =================== =============================
>
> diff --git a/Documentation/usb/gadget-testing.rst
> b/Documentation/usb/gadget-testing.rst
> index 29072c166d23..24a62ba8e870 100644
> --- a/Documentation/usb/gadget-testing.rst
> +++ b/Documentation/usb/gadget-testing.rst
> @@ -790,14 +790,19 @@ Function-specific configfs interface
> The function name to use when creating the function directory is "uvc".
> The uvc function provides these attributes in its function directory:
>
> - =================== ================================================
> - streaming_interval interval for polling endpoint for data transfers
> - streaming_maxburst bMaxBurst for super speed companion descriptor
> - streaming_maxpacket maximum packet size this endpoint is capable of
> - sending or receiving when this configuration is
> - selected
> - function_name name of the interface
> - =================== ================================================
> + =================== ===========================================
> + streaming_interval interval for polling endpoint for data
> + transfers
> + streaming_maxburst bMaxBurst for super speed companion
> + descriptor
> + streaming_maxpacket maximum packet size this endpoint is
> + capable of sending or receiving when
> + this configuration is selected
> + streaming_max_usb_requests upper bound for the number of usb
> requests
> + the gadget driver will allocate for
> + sending to the endpoint.
> + function_name name of the interface
Note, your patch is whitespace damaged and line-wrapped, making it
really really hard to read and impossible to apply.
thanks,
greg k-h
next prev parent reply other threads:[~2023-10-08 5:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 22:03 uvc gadget: Making upper bound of number of usb requests allocated configurable through configfs Jayant Chowdhary
2023-10-08 5:45 ` Greg KH [this message]
2023-10-09 22:34 ` Jayant Chowdhary
2023-10-12 18:50 ` Thinh Nguyen
2023-10-16 4:33 ` Jayant Chowdhary
2023-10-18 13:28 ` Michael Grzeschik
2023-10-19 23:15 ` Michael Grzeschik
2023-10-20 5:52 ` Jayant Chowdhary
2023-10-20 12:49 ` Michael Grzeschik
2023-10-27 8:12 ` Laurent Pinchart
2023-10-20 23:30 ` Thinh Nguyen
2023-10-23 18:13 ` Jayant Chowdhary
2023-10-24 12:33 ` Michael Grzeschik
2023-10-25 23:09 ` Jayant Chowdhary
2023-10-26 6:55 ` Michael Grzeschik
2023-10-27 8:14 ` Laurent Pinchart
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=2023100834-statistic-richly-49ef@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=arakesh@google.com \
--cc=corbet@lwn.net \
--cc=dan.scally@ideasonboard.com \
--cc=etalvala@google.com \
--cc=inux-doc@vger.kernel.org \
--cc=jchowdhary@google.com \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--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 NNTP newsgroup(s).