[Bug 297847] USB Serial Bulk Size is Hardcoded

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297847

            Bug ID: 297847
           Summary: USB Serial Bulk Size is Hardcoded
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: [email protected]
          Reporter: [email protected]

It appears that the bulk transfer sizes for several USB serial ports is
hardcoded within the implementation for each driver.

Example in uchcom:

[Constant
definition](https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uchcom.c#n167)
[Use in structure
size](https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uchcom.c#n243)


I see this behaviour on my machine with a particular CH340 device with a
`usbdump` capture and analysis in Wireshark; the bulk endpoint transfer covers
multiple packets (the device specifies a max packet size of 32) with a total
payload of 1024 bytes. 

Would it be possible and advantageous to expose the bulk size via a sysctl,
usbconfig setting, or other runtime-tunable value?

Personally, I'm trying to read data from a hardware measurement device. This
runs at a sample rate at least 500Hz and baud 921600. Serial emulation is far
from ideal for this scenario (isochronous would be much more sensible), but,
that's somehting that can't be changed right now - and for other setups, might
be impossible to change if interfacing with a proprietary device; within
digital electronics, serial is all too common even if it's far from optimal as
a communication method.

Each "frame" my measurement device streams is small, and the page size of 1024
is therefore causing multiple frames to back up be received at once, causing a
pretty significant latency that then is invalidating the data once received.

I understand this scenario is highly specific - but would there be any harm in
exposing the bulk size as something the user can tune? By comparison, a similar
usbmon capture on the linux kernel shows frames of varying size, but generally,
<64 bytes. The data therefore are buffered by the kernel with much lower
latency, and likewise, read calls in userspace to process this and send
downstream.

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.