Re: [PATCH 5/5] usb_debug: EXPERIMENTAL - poll hcd device to force writes

[Greg KH <greg@kroah.com>]

On Wed, May 06, 2009 at 11:18:07AM -0400, Alan Stern wrote:
> On Tue, 5 May 2009, Jason Wessel wrote:
> 
> > The problem that this patch tries to solve is that data is lost
> > because there are too many outstanding transmit urb's.
> > 
> > The question is what is the right way to force the controller to catch
> > up, and ideally let the kernel do some other things in the mean time?
> 
> What do standard serial port drivers do?

Not this :)

They use the proper flow control hooks that the tty layer provides.

> > This patch takes the route of forcibly polling the hcd device to drain
> > the urb queue and initiate the bulk write call backs.
> > 
> > NOTE this patch is not signed off, it is a question of what is the
> > right way to do this?
> 
> This patch is highly questionable.

I agree.

> Is the idea to force the HCD to search for completed URBs before the
> host controller has issued a completion interrupt?  Wouldn't it be
> better instead to use more URBs?
> 
> Besides, why should there be too many outstanding transmit URBs?  A
> normal serial debugging port running at 115200 baud can transmit no
> more than 12 bytes per ms.  You should be able to surpass that using
> only three URBs!  In fact, if you buffer up to 8 bytes per URB then
> with only two URBs you could send 64 bytes per ms, which is equivalent
> to 640000 baud.  Do you really need to go more than (say) ten times
> faster than that?

Yeah, something seems wrong here.

Jason, why is this really needed?  With your ring buffer, you shouldn't
need this at all anymore.

Or if you do, just bump up the number outstanding urbs that are
possible.  Or the urb buffer size.

This patch isn't acceptable as-is.

thanks,

greg k-h