device filtering support

[Xiaofan Chen]

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.

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.

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.

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).

-- 
Xiaofan