Date: Mon, 22 Dec 2014 10:48:34 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Kohji Okuno <okuno.kohji@jp.panasonic.com> Cc: freebsd-usb@freebsd.org Subject: Re: About XHCI_TD_PAGE_SIZE. Message-ID: <5497E8F2.5080800@selasky.org> In-Reply-To: <20141222.183157.253796126986510571.okuno.kohji@jp.panasonic.com> References: <549541BC.6070505@selasky.org> <20141222.103833.2105768702793613386.okuno.kohji@jp.panasonic.com> <5497E016.7020809@selasky.org> <20141222.183157.253796126986510571.okuno.kohji@jp.panasonic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/22/14 10:31, Kohji Okuno wrote: > In an optimisation, we should reduce the number of LINK_TRB, too. > I heard from a LSI engineer that, > Generally xhci controler has the cache of TRB array. But, LINK_TRB > may make the cache miss. Hi, One reason for the additional link TRB's is that I think there is different behaviour among the XHCI implementations how and when they generate a completion event. Any changes we make in that area needs to be tested with different XHCI controllers. Currently only the umass driver will use transfers greater than 64KBytes in case of USB 3.0. Else the most common case is transfers below 64KBytes, except for custom apps. I have another idea pending, which is related to performance, but not the XHCI. I was thinking that the FreeBSD libusb could be extended to allocate a data buffer in the kernel which then gets mmapped to userspace, to save copying/copyout of USB transfer data. The problem about mmap() is that the buffers cannot be freed afterwards, and must remain in the kernel. What do you think? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5497E8F2.5080800>