Re: [usbip-devel] number of packets in RET_SUBMIT

[Max V. <ma...@hi...>]

Hi Arjan,

On Tue, Mar 22, 2011 at 01:17:29PM +0100, Arjan Mels wrote:
> In the mean time I have found another bug in the handling of isochronous
> transfers, which affects both the linux & windows version: Only actual_length
> bytes of the buffer are transferred, however for isochronous transfers the
> actual_length is the sum of the actual_length of the packets and if the
> actual length of a single packet is shorter the offsets will not change, so
> padding between the packets will be present, so a relevant part of the buffer
> is not tranmitted

Good catch.

I have no experience working with ISO transfers, so I am 
just going to pose some questions.

> There are two ways to fix this: 
> 1) Adjust the actual_length transmitted in the header to the total length of
> the buffer and transmit the entire buffer: If this is done only the server
> needs to be adapted, both linux & windows clients can remain unchanged.

The clients would get a different actual_length in the
completed URB then? I don't know if there are any drivers
which rely on actual_length to have the original value.

> 2) The paddings inbetween the packets can be removed (= not transmitted).
> This means changing both server and both client version. However considerable
> bandwidth can be saved. E.g. width by DVB-C tuner usb stick the bandwidth
> goes from approx 6.6MByte/s to 4.2MByte/s.

I am wondering, would you restore the padding then on the
client side, or is a HCD allowed to modify the offsets in 
the ISO packet descriptors?

> I intend/propose to make 3 separate patches to the staging driver in the kernel:
> 1) Fix the number_of_packets in stub_common.c
> 2) Change actual_length to buffer length in stub_rc.c in case of isochronous transfers
> 3) Only transmit the necessary parts of the buffer for isochronous transfers

> (for this patch I intend to bump the protocol version number as it is in
> principle a breaking change)

I think bumping the protocol version may be difficult.

The version checks are all done in userspace, which has
no way to tell which version of the kernel drivers are
currently being used.

> I have been reading and I think I need to submit the patches to Greg Kroah.
> Is that correct?

Yes. You can Cc them to me and usbip-devel to get more
review feedback.

> In parallel I will make the necessary patches to the user land tools. 
> 
> For me the good news is that I now actually have my DVB-C tuner connected to
> a Netgear Router fully working on my Windows computers (so I didn't need to
> pull extra antenna cables to my computers...)!
> 
> Next steps I intend to work on are the user friendliness of the user land
> tools (e.g. auto bind the driver after a reconnect and/or make binding
> controllable via the tcp/ip connection and a GUI for windows)

Sounds great.

	Max