Hi, On Wed, Jun 15, 2011 at 11:24:25AM +0800, Bob Liu wrote: > On Tue, Jun 14, 2011 at 6:28 PM, Felipe Balbi <balbi@xxxxxx> wrote: > > On Tue, Jun 14, 2011 at 12:25:11PM +0200, Mikael Abrahamsson wrote: > >> (taking it offlist just because I have no idea about anything really) > > > > c'mon, quite good point below ;-) > > > >> >yeah, but if the problem isn't throughput, I don't see how MUSB > >> >could be to blame here. The network priority should have been > >> >handled by IP layer and the controller shouldn't matter, right ? > >> > >> I'm just a silly router guy, but I've seen on router platforms that > >> when the device driver has a big buffer (FIFO) that the IP layer > >> feeds into (which then does some kind of priority scheduling of > >> packets), one loses a lot of QoS capabilities. > > > > MUSB doesn't have any big buffers of its own. In this situation it's > > using the buffers from usbcore. So it should be the same on the ISP1362 > > host ;-) > > > > Good point anyway :-D > > > >> So the device driver can indeed cause these kinds of problems, if it > >> doesn't push back the congestion to the IP layer properly. Also if > >> the device FIFO buffer drops packets on its own the same behaviour > >> can be seen. > > > > USB won't drop packets unless you explicitly tell it to flush the HW > > FIFOs. I don't think this is the case here either. > > > > Actually I saw this happen because wireless driver called usb_unlink_urb(). > i don't know what's ISP1362 did in this situation, but it seems musb > will flush the HW FIFOs. > Maybe this will cause the priority problem ? I am not sure :-). yes, in that case it will. But that's explicitly telling it to cancel that packet. Then it will give it back with -ECONNRESET and if it was already on HW control, it will abort the packet and flush the FIFO. Why does wireless driver need to call usb_unlink_urb() ? -- balbi
Attachment:
signature.asc
Description: Digital signature
