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
Some xhci (USB3) controllers have a constraint on the offset within a
bulk transfer of the end of the transfer ring.
The xhci documentation (v1.00, but not the earlier versions) states that
the offset (from the beginning of the transfer) at end of the transfer
ring must be a multiple of the burst
28 matches
Mail list logo
