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.
But rather the
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 be
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
controllers.
It is
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 ..
No,
On Sat, Feb 1, 2014 at 9:30 PM, Mark Lord ml...@pobox.com 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 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 of
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).
So
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 userspace.
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 sarah.a.sh...@linux.intel.com writes:
Let's do this fix the right way, instead of wall papering
On Fri, Jan 31, 2014 at 08:17:58AM +0800, Ming Lei wrote:
On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com 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
On Sat, Feb 1, 2014 at 3:00 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com 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
sarah.a.sh...@linux.intel.com wrote:
On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
FWIW, the
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 fragments.
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 body of
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 back and
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 xhci: Set
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
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
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 to the
FWIW, the plan looks fine to me. Just adding a couple of hints to
simplify the implementation.
Sarah Sharp sarah.a.sh...@linux.intel.com 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
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 fundamental
Sarah Sharp sarah.a.sh...@linux.intel.com 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
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, but it's
On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com 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 sarah.a.sh...@linux.intel.com writes:
23 matches
Mail list logo
