public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: "Grossman, Jake" <Jacob.Grossman@drs.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"Krebs, Charles" <Charles.Krebs@drs.com>,
	"Hardee, Hayden M" <Hayden.Hardee@drs.com>
Subject: Re: usb: dwc3: gadget performance insight
Date: Wed, 17 Apr 2024 08:42:23 +0200	[thread overview]
Message-ID: <2024041752-tutu-sliceable-2e18@gregkh> (raw)
In-Reply-To: <20240416223109.ckmljamgjc53sbpr@synopsys.com>

On Tue, Apr 16, 2024 at 10:31:19PM +0000, Thinh Nguyen wrote:
> On Tue, Apr 16, 2024, Grossman, Jake wrote:
> > Hello,
> > 
> >  
> > 
> > We’re trying to operate a USB gadget backed by the DWC3 core on an iMX8
> > processor, but we are seeing issues with performance.
> > 
> >  
> > 
> > As a comparison, utilizing iperf3 to benchmark, we are able to see ~230Mbit/s
> > with an RNDIS gadget, and ~900Mbit/s with a hardware USB-to-Ethernet
> > peripheral.
> > 
> 
> What is "a hardware USB-to-Ethernet peripheral"? Does it use the same
> RNDIS function driver and the same kernel version? If not, you're
> comparing 2 very different things. Also, I assume that you're testing
> against the same host.
> 
> >  
> > 
> > Looking at the output of perf, we are seeing that with all of the gadget
> > drivers (RNDIS, UVC, ACM), there is significant time spent spinning in an IRQ
> > context that does not occur with the hardware peripheral. This seems like it
> > might be related to the interrupt handler as described here: https://
> > docs.kernel.org/usb/dwc3.html.
> > 
> >  
> > 
> >  1. We have not yet acquired technical documentation regarding the DWC3
> >     module.  Do you have a list of the DWC3 commands that have high latency
> >     (~1ms)?
> >  2. Do you believe that implementing a per endpoint IRQ framework will resolve
> >     the large disparity in performance?  If not, do you have any insight into
> >     what the root cause might be?
> > 
> 
> I'm not familiar with RNDIS. However, my suspicion is that RNDIS
> transfers are small, and they may not take advantage of USB burst. Or
> perhaps your platform doesn't setup the TxFIFO size for performance? On
> a side note, isn't RNDIS getting outdated?

It's not only outdated, but incredibly insecure and should not be used
for anything unless you explicitly trust both ends of the connection.
Please never use it for anything real, including benchmarks.

I need to dust off my "delete the rndis code" patch set one of these
days...

thanks,

greg k-h

      reply	other threads:[~2024-04-17  6:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <PH1P110MB1489614D2BD4B34E66B9A3208334A@PH1P110MB1489.NAMP110.PROD.OUTLOOK.COM>
2024-04-16 14:20 ` usb: dwc3: gadget performance insight Grossman, Jake
2024-04-16 22:14   ` Wesley Cheng
2024-04-16 22:31   ` Thinh Nguyen
2024-04-17  6:42     ` Greg KH [this message]

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=2024041752-tutu-sliceable-2e18@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=Charles.Krebs@drs.com \
    --cc=Hayden.Hardee@drs.com \
    --cc=Jacob.Grossman@drs.com \
    --cc=Thinh.Nguyen@synopsys.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