LibUSB › LibUSB Dev

[libusb] #137: transfers are being splitted to small URBs for no reason

Classic

List

Threaded

13 messages Options

libusb Trac

[libusb] #137: transfers are being splitted to small URBs for no reason

#137: transfers are being splitted to small URBs for no reason
---------------------+---------------------------------------
Reporter: parafin | Owner:
Type: defect | Status: new
Milestone: | Component: libusb-1.0 Linux backend
Keywords: | Blocked By:
Blocks: |
---------------------+---------------------------------------
Currently if bulk transfer larger than 16 KB is submitted, it's splitted
into several URBs not larger than 16KB. Comments in code suggest, that
Linux can't handle larger buffers, which is incorrect (at least now, maybe
it was true in the past). I've changed MAX_BULK_BUFFER_LENGTH from 16384
to 1048576 (1 MB) and nothing broke (see attached patch). Actually it
solved problems I've been having with USB3. Splitting big transfers
increase interrupt and memory load and it seams that xhci kernel driver
doesn't handle this situation well which ends in data corruption.
Same issue probably applies to isochronous transfers.

--
Ticket URL: <https://libusb.org/ticket/137>
libusb <https://libusb.org/>
C library for writing portable USB drivers in userspace
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb Trac

Re: [libusb] #137: take advantage of new kernel support for large transfers (was: transfers are being splitted to small URBs for no reason)

#137: take advantage of new kernel support for large transfers
--------------------------+--------------------------------------
Reporter: parafin | Owner:
Type: enhancement | Status: new
Milestone: | Component: libusb-1.0 Linux backend
Resolution: | Keywords:
Blocked By: | Blocks:
--------------------------+--------------------------------------
Changes (by stuge):

* type: defect => enhancement

Comment:

The reason to split transfers is that older kernels only supported 16kb
transfers anyway.

This has changed and is changing even more right this moment, as Hans is
working on new usbfs API which will make large transfers from userspace
both simpler and more efficient. I believe he may also do the libusb side
work for this, so let's see how that turns out.

Increasing the (by now) arbitrary limit of 16kb to another arbitrary
limit, although larger, isn't a very nice solution. The kernel work being
done is the real fix.

We just have to be careful to remain backwards compatible. libusb has to
continue working fine even on the way old kernels which only do 16kb
transfers.

In any case thank you for the ticket, this is an important improvement for
USB 3 on Linux!

--
Ticket URL: <https://libusb.org/ticket/137#comment:1>
libusb <https://libusb.org/>
C library for writing portable USB drivers in userspace
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb Trac

Re: [libusb] #137: take advantage of new kernel support for large transfers

In reply to this post by libusb Trac

#137: take advantage of new kernel support for large transfers
--------------------------+--------------------------------------
Reporter: parafin | Owner:
Type: enhancement | Status: new
Milestone: | Component: libusb-1.0 Linux backend
Resolution: | Keywords:
Blocked By: | Blocks:
--------------------------+--------------------------------------

Comment (by hansdegoede):

Replying to [comment:1 stuge]:
> This has changed and is changing even more right this moment, as Hans is
working on new usbfs API which will make large transfers from userspace
both simpler and more efficient. I believe he may also do the libusb side
work for this, so let's see how that turns out.

Correct, see my patch here:
http://sourceforge.net/mailarchive/message.php?msg_id=29475836

As indicated on that thread the new kernel-APIs this depends on are not
yet upstream (but they have got a positive reception, so I expect them to
go upstream soon).

As for raising the limit to 1 MB, this is a very '''bad''' idea, usbfs
needs a bounce buffer to copy the userspace buffer data to/from, and this
buffer needs to be dma-able and thus '''physically contiguous''', the
chances of there being a 1MB physically contiguous area of memory free on
a system which has been running for a while is actually very small, so
transfers of 1MB will likely fail when not split. My kernel work allows
submitting these kind of transfers in one go by using scatter-gather lists
to split the transfer up inside the kernel on usb controllers which
support scatter-gather. Note that even with this kernel patch it is still
a bad idea to submit large transfers on non scatter-gather capable
controllers. So my patchset also adds a new kernel API to query the
devices capabilities, and teaches libusb how to use it.

--
Ticket URL: <https://libusb.org/ticket/137#comment:2>
libusb <https://libusb.org/>
C library for writing portable USB drivers in userspace
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb Trac

Re: [libusb] #137: take advantage of new kernel support for large transfers

In reply to this post by libusb Trac

Alan Stern

Re: [libusb] #137: take advantage of new kernel support for large transfers

On Mon, 2 Jul 2012, libusb Trac wrote:

> #137: take advantage of new kernel support for large transfers
> --------------------------+--------------------------------------
> Reporter: parafin | Owner:
> Type: enhancement | Status: new
> Milestone: | Component: libusb-1.0 Linux backend
> Resolution: | Keywords:
> Blocked By: | Blocks:
> --------------------------+--------------------------------------
>
> Comment (by timrprobocom):
>
> Replying to Hans:
> > ... this buffer needs to be dma-able and thus '''physically
> contiguous''' ...
>
> All USB host controllers support scatter/gather DMA. The kernel-side
> buffer does not need to be physically contiguous.

While that is true, the usbfs API that Hans is modifying currently
allocates only a single contiguous extent. The modification causes
usbfs to allocate a discontiguous buffer. The description could stand
to be improved a little...

Alan Stern

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb Trac

Re: [libusb] #137: take advantage of new kernel support for large transfers

In reply to this post by libusb Trac

#137: take advantage of new kernel support for large transfers
--------------------------+--------------------------------------
Reporter: parafin | Owner:
Type: enhancement | Status: new
Milestone: | Component: libusb-1.0 Linux backend
Resolution: | Keywords:
Blocked By: | Blocks:
--------------------------+--------------------------------------

Comment (by hansdegoede):

Replying to [comment:3 timrprobocom]:
> Replying to Hans:
> > ... this buffer needs to be dma-able and thus '''physically
contiguous''' ...
>
> All USB host controllers support scatter/gather DMA. The kernel-side
buffer does not need to be physically contiguous.

<sigh>, it would have been helpful if you read further down before
shooting of a quick comment from the hip. I've been only working on USB
for a couple of years now, and on the large bulkt ransfers with XHCI
controllers issue for a full month...

Besides knowing what I'm talking about the answer to your comment is
actually further down in the comment you're replying on: "My kernel work
allows submitting these kind of transfers in one go by using scatter-
gather lists to split the transfer up inside the kernel on usb controllers
which support scatter-gather."

IOW yes the controllers are scatter-gather capable, but the usbfs layer in
the kernel is (was) not using this, since until recently the urb data size
was limited to 16k, so there was no need to use scatter-gather.

See here for the kernel patches adding scatter-gather support to usbfs:
http://www.spinics.net/lists/linux-usb/msg66567.html

--
Ticket URL: <https://libusb.org/ticket/137#comment:4>
libusb <https://libusb.org/>
C library for writing portable USB drivers in userspace
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

libusb Trac