On Mon, Feb 03, 2014 at 09:54:09AM +, David Laight wrote:
> From: Mark Lord
> > On 14-02-01 09:18 AM, Ming Lei wrote:
> > >
> > > Even real regressions are easily/often introduced, and we are discussing
> > > how to fix that. I suggest to unset the flag only for the known buggy
> > > controller
On Sat, Feb 01, 2014 at 03:05:21PM -0500, Mark Lord wrote:
> On 14-02-01 09:18 AM, Ming Lei wrote:
> >
> > Even real regressions are easily/often introduced, and we are discussing
> > how to fix that. I suggest to unset the flag only for the known buggy
> > controllers.
Ming, the regression cannot
From: Mark Lord
> On 14-02-01 09:18 AM, Ming Lei wrote:
> >
> > Even real regressions are easily/often introduced, and we are discussing
> > how to fix that. I suggest to unset the flag only for the known buggy
> > controllers.
>
> It is not the controllers that are particularly "buggy" here.
> Bu
On 14-02-01 09:18 AM, Ming Lei wrote:
>
> Even real regressions are easily/often introduced, and we are discussing
> how to fix that. I suggest to unset the flag only for the known buggy
> controllers.
It is not the controllers that are particularly "buggy" here.
But rather the drivers and design
On Sat, Feb 1, 2014 at 9:30 PM, Mark Lord wrote:
> On 14-02-01 02:54 AM, Ming Lei wrote:
> ..
>> With SG enabled, for the iperf client test case, the average urb size
>> for transmission will be increased from ~1500 to ~20K bytes in my
>> test case:
>>
>>iperf -c $SRV -t 30 -P 4 -w 128K
>>
>>
On 14-02-01 02:54 AM, Ming Lei wrote:
..
> With SG enabled, for the iperf client test case, the average urb size
> for transmission will be increased from ~1500 to ~20K bytes in my
> test case:
>
>iperf -c $SRV -t 30 -P 4 -w 128K
>
> So I am wondering you guys do not care the improvement ..
On Sat, Feb 1, 2014 at 3:00 AM, Sarah Sharp
wrote:
> On Fri, Jan 31, 2014 at 08:17:58AM +0800, Ming Lei wrote:
>> On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
>> wrote:
>> > On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
>> >> FWIW, the plan looks fine to me. Just adding a couple of
On Fri, Jan 31, 2014 at 08:17:58AM +0800, Ming Lei wrote:
> On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
> wrote:
> > On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
> >> FWIW, the plan looks fine to me. Just adding a couple of hints to
> >> simplify the implementation.
> >>
> >> Sara
From: Sarah Sharp
> On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
> > FWIW, the plan looks fine to me. Just adding a couple of hints to
> > simplify the implementation.
> >
> > Sarah Sharp writes:
> >
> > > Let's do this fix the right way, instead of wall papering over the
> > > iss
From: Peter Stuge [mailto:pe...@stuge.se]
> > Userspace doesn't care since everything gets copied into aligned
> > kernel fragments - otherwise the other usb controllers wouldn't work.
>
> OK, but not so great if someone wants to squeeze the most performance
> possible out of USB also from userspa
David Laight wrote:
> > We shouldn't need to make userspace start to worry about alignment at
> > all. libusb worked in the past, before the link TRB fix went in. We
> > *cannot* break userspace USB drivers. The breakage needs to be fixed in
> > the USB core or the xHCI driver.
>
> Userspace do
From: Sarah Sharp
> We need to step back and reassess the larger picture here, instead of
> trying to fire-fight all the regressions caused by the link TRB commit
> (35773dac5f86 "usb: xhci: Link TRB must not occur within a USB payload
> burst").
Some of the breakage seems to have been related to
From: Peter Stuge
> But what about that alignment? It seems that userspace
> needs to start caring about alignment with xhci, right?
No because there is a copy_to/from_user() in the middle.
The ehci/ohci/uhci all require that fragments be a multiple of the
usb message size (512 bytes for USB2).
S
On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
wrote:
> On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
>> FWIW, the plan looks fine to me. Just adding a couple of hints to
>> simplify the implementation.
>>
>> Sarah Sharp writes:
>>
>> > Let's do this fix the right way, instead of wal
On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
> FWIW, the plan looks fine to me. Just adding a couple of hints to
> simplify the implementation.
>
> Sarah Sharp writes:
>
> > Let's do this fix the right way, instead of wall papering over the
> > issue. Here's what we should do:
>
On Thu, 30 Jan 2014, Sarah Sharp wrote:
> > That's a good plan. However _some_ restriction will turn out to be
> > necessary.
> >
> > For example, what will you do if a driver submits an SG list containing
> > 300 elements, each 3 bytes long? That's too many to fit in a single
> > ring segment,
Sarah Sharp writes:
> On Thu, Jan 30, 2014 at 04:43:54PM -0500, Alan Stern wrote:
>
>> ehci-hcd gets along okay with the restriction that each SG element
>> except the last has to be a multiple of the maxpacket size. xhci-hcd
>> can relax this quite a lot, but not all the way.
>
> What does the
On Thu, Jan 30, 2014 at 04:43:54PM -0500, Alan Stern wrote:
> On Thu, 30 Jan 2014, Sarah Sharp wrote:
>
> > It should not matter what alignment or length of scatter-gather list the
> > upper layers pass the xHCI driver, it should just work. I want to do
> > this fix right, by changing the fundame
FWIW, the plan looks fine to me. Just adding a couple of hints to
simplify the implementation.
Sarah Sharp writes:
> Let's do this fix the right way, instead of wall papering over the
> issue. Here's what we should do:
>
> 1. Disable scatter-gather for the ax88179_178a driver when it's under a
On 14-01-30 04:43 PM, Alan Stern wrote:
> On Thu, 30 Jan 2014, Sarah Sharp wrote:
>
>> It should not matter what alignment or length of scatter-gather list the
>> upper layers pass the xHCI driver, it should just work. I want to do
>> this fix right, by changing the fundamental way we queue TRBs
On Thu, 30 Jan 2014, Sarah Sharp wrote:
> It should not matter what alignment or length of scatter-gather list the
> upper layers pass the xHCI driver, it should just work. I want to do
> this fix right, by changing the fundamental way we queue TRBs to the
> rings to fit the TD rules. We should
Sarah, on a related note:
Is there a parameter or knob of some kind to tell the XHCI driver
to treat a specific port as USB2 (480mbit/sec max) rather than USB3 ?
The Dell XPS-13 Ultrabooks all suffer from some kind of flaw, whereby the left
side
USB3 port is unreliable at SuperSpeed; the right s
On 14-01-30 04:18 PM, Sarah Sharp wrote:
>
> Let's do this fix the right way, instead of wall papering over the
> issue. Here's what we should do:
>
> 1. Disable scatter-gather for the ax88179_178a driver when it's under an
>xHCI host.
>
> 2. Revert the following commits:
>f2d9b991c549 x
On Thu, Jan 30, 2014 at 05:35:08PM +0100, Peter Stuge wrote:
> David Laight wrote:
> > > Where's the 8k coming from?
> >
> > My memory, I meant 16k :-(
>
> No problem. But what about that alignment? It seems that userspace
> needs to start caring about alignment with xhci, right?
We need to step
David Laight wrote:
> > Where's the 8k coming from?
>
> My memory, I meant 16k :-(
No problem. But what about that alignment? It seems that userspace
needs to start caring about alignment with xhci, right?
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the bo
From: Peter Stuge
...
> > code using libusb can generate arbitrarily long transfers that usually
> > get split into 8k fragments.
>
> libusb splits transfers into 16k urbs, or doesn't with newer code
> when both kernel and libusb support scatter-gather.
>
> > In fact libusb always uses 8k fragme
David Laight wrote:
> Some xhci (USB3) controllers have a constraint on the offset within a
> bulk transfer of the end of the transfer ring.
Mhm.
> code using libusb can generate arbitrarily long transfers that usually
> get split into 8k fragments.
libusb splits transfers into 16k urbs, or doe
27 matches
Mail list logo
