device filtering support

[Vitali Lovich]

On Feb 6, 2012, at 12:03 AM, Xiaofan Chen wrote:

> On Sun, Feb 5, 2012 at 10:15 AM, Vitali Lovich <vlovich at gmail.com> wrote:
>> Isochronous traffic has a guaranteed portion of USB bandwidth
>> allocated + have guarantees on latency.  Bulk & control transfers
>> cannot interfere with that.  So you doing any other USB traffic
>> would not cause any interference as described.  I find it highly
>> unlikely given how USB works that we could cause issues with
>> other applications.  USB applications already have to be robust in the
>> case of increased traffic or interleaved traffic (hence the reason only 1
>> claim of an interface is allowed at the same time).
> 
> I have some discussions with Travis and here is the reply.
> 
> In a perfect world, indeed you may well be right about bulk transfer
> and control transfer device can deal with the increased traffic.
> But in reality it may not. For example, DFU (device firmware
> upgrade) relies on control transfer. With the increased traffic,
> the host program may have time out and the whole process
> breaks down if the firmware and host software are not
> well written.
I in fact have a DFU application running on top of libusb & am pretty familiar with the DFU spec.  It's a pretty robust, simple spec.  Even if transfers timeout, the entire state machine is interlocked on both ends, so you're unlikely to cause actual problems.  So yes, you have to follow the spec, but it's not all that complex to begin with & I'm inclined that the majority of implementations are actually solid given how critical it is for it not to fail.

And the question is, is it actually possible to generate that much traffic; the only control requests, aside from reading the device descriptor, is sending DFU commands; all other control requests will generate an error.  And you also can't generate all that much traffic via control requests; packets are limited to what, 64 bytes?  & you're fairly limited about how many packets you can send. 

> For ISO device, the situation is different. Indeed the bandwidth
> are allocated and it is not the issue. Rather it is more issue
> with the device side. Take note even if the bandwidth is there,
> the device must have the data ready. If not, it may miss the
> service interval and thus causes packet loss.
> 
> In this case, ISO devices that are already starved for MIPS may
> drop packets which has nothing to do with allocated bandwidth.
> But rather it is because the device is busy responding to descriptor
> request instead of processing data. When its service interval
> comes around, it doesn't have a complete packet because
> it was busy responding to control requests.
Now this scenario is slightly more convincing.  I am slightly more inclined to believe that the device must have sufficient MIPS to respond to the control request without dropping packets; the reason being that the USB spec, AFAIK, doesn't provide any guarantees about the frequency or timing of control messages; thus a control message could always come in at the wrong time.  However, the spec does talk about latency & throughput guarantees; those guarantees must extend to the device USB stack as well.
> 
> All in all these are still theoretical analysis and we will try to
> come out with some test cases to see if we can reproduce
> real world examples to demonstrate the problems. In any
> case, I still see the current enumerations under Windows
> (and Mac OS X as well) as having performance issues which
> the user may or may not want to live with.
That's what I've been asking for.
> 
> Right now I am more inclined to Segher's compromised
> proposal of give user the option of using filter to reduce
> unnecessary traffic (please refer to my previous reply).
Yeah, I'm pretty sure it's possible to convert VID/PID to GUIDs, or to determine the VID/PID without actually querying the device; after all, the VID & PID are encoded in the device instance path.

-Vitali