Message-ID: <559433E7.2030100@redhat.com>
Date:	Wed, 1 Jul 2015 20:39:35 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Greg KH <greg@...ah.com>, Jeremy White <jwhite@...eweavers.com>
Cc:	spice-devel@...ts.freedesktop.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect
 USB devices over IP.

Hi,

On 01-07-15 18:13, Greg KH wrote:
> On Wed, Jul 01, 2015 at 10:55:49AM -0500, Jeremy White wrote:
>> On 07/01/2015 12:44 AM, Greg KH wrote:
>>> On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote:
>>>>    1.  Is the basic premise reasonable?  Is Hans correct in asserting that an
>>>> alternate USB over IP module will be considered?
>>>
>>> I have no idea, if it fully replaces the usbip functionality, I don't
>>> see why that would be rejected.  But why can't you just fix up usbip for
>>> the issues you find lacking?
>>
>> This is what Hans said 5 years ago: [1]
>>
>>>
>>> 3) The protocol itself is far from ideal.
>>>
>>> Number 3 is the big deal breaker for me. I've looked at the
>>> (undocumented) protocol by sifting through the source. And it is
>>> very low level, all it does is shove usb packets back and forth
>>> over the network. It has no concept of configuration
>>> setting (the docs say make sure the device is in the right
>>> configuration before sharing it). No concept of caching things
>>> like descriptors, active configuration, per interface alt setting,
>>> etc.
>>>
>>> Besides missing a lot of useful smarts the whole one packet at a
>>> time approach does not really fly when it comes to isoc endpoints.
>>> As there paper states, the vm-host / guest os drivers need to
>>> make sure enough packets are submitted / queued at all time
>>> to gap the network delay / fill the network pipe.
>>>
>>> For iso endpoints it makes much more sense to have a start / stop
>>> stream model, where the usb-host "pumpes" the urb ringbuffer and
>>> sends out data received from the usb device to the vm-host
>>> (isoc input endp case), or sends data received from the vm-host
>>> (through a buffer to deal with network jitter) to the isoc output
>>> endpoint.
>>>
>>> This also halves the number of packets which need to be
>>> send over the network, as their is no need for the vm-host to send
>>> a request for each packet once an input stream has started / for
>>> the usb-host to send an ack for each delivered packet for an ouput
>>> stream. It would still send an error when an error occurs, but their
>>> is no reason to ack all delivered packets. Given the delay
>>> caused by buffering, etc. not being able to match up the error to
>>> an exact packet is not important, as from the vm-host emulated usb
>>> hc (host controller), the packet has long been delivered already.
>>>
>>> Instead we will simply report the error to the guest os for the
>>> next packet enqueued by the guest after receiving notification of
>>> the error from the usb-host.
>>
>> The protocol is now documented, so that part is out of date.  I don't
>> see any evidence that the bulk of his other concerns have been
>> addressed, however.
>
> Because no one has cared to.  Now it seems you care, so I'd prefer to
> see someone fix this up instead of adding another protocol that does
> much the same thing.

I understand where you are coming from, but usbip is unfixable as it
has no concept of capability negotiation, protocol versioning or some such.

What we need is an usbip v2, and usbredir was written as that, and has been
used in production for years now for redirection of usb devices from
virtual-machine-viewers into qemu based virtual-machines.

I understand that having 2 protocols for one thing is undesirable in
general, but think of this as usb-mass-storage bulk transport vs uas,
or ipv4 vs ipv6 in some cases it just is necessary to do a new
better protocol.

When I designed and implemented usbredir usbip was pretty much dead, but it
got ressurected later. I've never spoken up on this and never attempted to
block usbip's promotion out of staging, as that seemed unfair since no-one
was working on a virtual-hcd driver for the usbredir protocol.

Likewise I think it is unfair if my not speaking up back then now blocks
an usbredir virtual-hcd driver from entering the kernel.

Regards,

Hans
--
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/

Powered by blists - more mailing lists