Re: [PATCH 5/5] usb_debug: EXPERIMENTAL - poll hcd device to force writes

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

>     Write routine:
> 	Copy bytes into the available URB buffers, submitting URBs as 
> 	they get filled.  At the end, if the next URB is partially full 
> 	then submit it only if NIF < P.

There are good known algorithms for this and essentially the logic is
about speed and time estimation. You don't need to queue a partially
filled URB until you reach the time point that the hardware is in danger
of having sent everything already queued. So under load once you've
stuffed 4K down the pipe you know at 38400 baud that you can relax for
quite some time.

You could even entirely decouple write() from sending URBs.

>     Completion routine:
> 	If the next URB to send is partially filled, submit it.
> 
>     write_room routine:
> 	Return the actual number of bytes remaining in the available 
> 	URBs, but no more than (N-P)*B.

Providing your URBs can be allocated to say 512 bytes an URB then it'll
work fine to simply return the bytes left in the last URB (max the bytes
in the last URB). The tty code will then end up going

	room ?
		512 bytes
		fire away
	room ? 
		512 bytes
		fire away
	room ?
		...

until you run short of space

> 
> How does that sound?  Converting \n to \r\n will add some complication 
> but not too much.  
> 
> Allocating URBs on the fly adds a lot of complication.  There has to be 
> a minimum number of pre-allocated URBs; otherwise write_room could 
> never return a positive value.  If you allocate additional URBs 
> later on, when would you free them?

write_room can allocate URBs I think (would need to be atomic allocations)

	write_room()
		if no_urbs && urbs_queued < max_queued
			allocate an urb
		return space_in_last_urb;