Re: xhci: "no room on ep ring" with USB2.0 high speed device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 15, 2011 at 04:42:44PM +0800, Andiry Xu wrote:
> On Fri, Jul 15, 2011 at 3:58 PM, Kruno Mrak <kruno.mrak@xxxxxxxxxxxxxxxx> wrote:
> > Hi,
> >
> > when running our cameras on USB3.0 ports we get
> > "ERROR no room on ep ring".
> > This only happens if camera's image size is bigger than
> > ~1MB or when using multiple image buffers (queueing).
> > Capturing is made through libusb and async bulk transfers.

What standard is your camera using?  The draft USB-AV standard?  Other
than that, I don't know of any camera standards that use bulk endpoints.
Are you submitting multiple bulk transfers to the same endpoint, or are
you submitting one bulk transfer and waiting on it?

Also, is your libusb app open source?  I'm just curious because there
is at least one other group I know of working on an open source USB-AV
implementation.

> > Now, as more and more of our customers are using PCIe-USB3.0 extension
> > cards we get under pressure.
> > After looking into xhci driver sources, i have seen that
> > TRBS_PER_SEGMENT is limited to 64 and segments per ep ring
> > is fixed to 1. (right?)
> 
> For bulk transfer, it's 1 segment. Isochronous transfer needs a bigger ring
> because it inserts multiple TDs to the ring when an isoc URB is submitted.
> Currently it uses 8 segments.

Yes, Andiry's right.  We never had a clear case for why people needed
bigger bulk rings.  VmWare did complain a bit that some of their test
cases didn't run properly for very large transfers, but I think they
didn't have any customers that actually used transfers that big.

> > Playing with this params (TRBS_PER_SEGMENT=256 and ep ring segments=8)
> > and first tests led to good results.

I would like to keep the TRBS_PER_SEGMENT parameter the same, because
otherwise I might to go change the streams code that uses a radix tree to
map DMA addresses to virtual addresses.  If you keep that to 64, how
many ring segments do you end up needing?

> > So, my question is, do you agree with me that limited
> > ep ring allocation might cause above mentioned error.
> > Is there a chance to push development on ep ring allocation?
> >
> > Thank you in advance.
> >
> 
> Maybe dynamic ring allocation helps in this situation.

Yes, it could help in this situation.  However, I don't have the
bandwidth right now to work on dynamic ring expansion.  The quick fix
would be to add a module parameter to the xHCI driver that sets the
number of ring segments to use for the four different types of
endpoints.  Perhaps parameters named bulk_segs, intr_segs, isoc_segs,
and ctrl_segs?

It sounds like you already know how to modify the xHCI driver, so do
you want to create a patch for this?

Also, is your camera already available commercially (USB-IF certified
and all that), or will it be soon?  If many Linux users are going to run
into this issue, the xHCI driver really needs dynamic ring expansion.
If we have some time before your product hits the market and your
customers are just testing out your product, I think the module
parameter would be an acceptable quick fix.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux