linux-kernel - Re: [PATCH] Increase usbfs bulk buffer size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 31 Aug 2011 08:57:28 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Increase usbfs bulk buffer size

Greg, Oliver,

can you justify why 190K is acceptable for Isochronous (which has been
in the kernel for a long long time now) but less than 50k is suddenly
not acceptable for bulk when using USBFS? Especially while the wild
out there already approved that 190K is okay even on embedded systems?
That's the only thing I would like to know :-)

We made many tests here (and have many more customers using Isoc 190k
buffers) and memory allocation has a much better performance instead
of pushing ioctls forward/backward for reading those small packets.
I do understand your concern but from my point and experience with it
(we've been using it for 3 years so far) it does not cause any
problem. We reached the 1k amount of users using 190k Isoc buffers a
long time ago, those are pushing 170 Mbit a second. The bulk purpose
is for 80mbit a second only.
I would just like to have all supported modes with performance and not
too many changes. Currently we only get good performance with
isochronous, bulk USBFS performance could just be better with Linux,
our software works well enough with Mac, Solaris and FreeBSD with Bulk
and Iso.

BR,
Markus

On Fri, Aug 19, 2011 at 12:45 PM, Markus Rechberger
<mrechberger@...il.com> wrote:
> On Fri, Aug 19, 2011 at 8:23 AM, Oliver Neukum <oliver@...kum.org> wrote:
>> Am Mittwoch, 17. August 2011, 19:44:16 schrieb Markus Rechberger:
>>> I understand that USBFS is not 100% optimized, although we are already
>>> using 3-4 times that much buffer with isochronous and it was working
>>> fine for years so far as long as the system doesn't run out of memory
>>> .. but even kerneldrivers would have issues with it in such a
>>> situation.
>>
>> The problem is not what happens on your test system dedicated to this use.
>> There it'll work. But you allowed everybody else to make the kernel request
>> the second largest chunk of memory there is. On a otherwise busy system
>> with fragmented memory this is not good.
>>
>> As I said, you want scatter/gather if you need this.
>> There still would be the problem with the API, but if this is really a problem,
>> you could define a new ioctl()
>>
>
> let's say there are a few thousand users of the 190k isochronous implementation.
> I don't want to add more complex code to the kernel, if it's not
> accepted I'm okay with it,
> since I know the performance impact I can recommend it to those who
> are interested in it.
> Our software works without it anyway, and Bulk is just for special use
> in our case.
>
> Best Regards,
> Markus
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/