linux-kernel - Re: [RFC, PATCH] USB: EHCI: Allow users to override 80% max periodic bandwidth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20110624165432.GA6415@tugrik.mns.mnsspb.ru>
Date:	Fri, 24 Jun 2011 20:54:32 +0400
From:	Kirill Smelkov <kirr@....spb.ru>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	linux-usb@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
	linux-uvc-devel@...ts.berlios.de, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC, PATCH] USB: EHCI: Allow users to override 80% max
	periodic bandwidth

On Thu, Jun 23, 2011 at 01:14:04PM -0400, Alan Stern wrote:
> On Thu, 23 Jun 2011, Kirill Smelkov wrote:
> 
> > > At 480 Mb/s, each microframe holds 7500 bytes (less if you count 
> > > bit-stuffing).  4% of that is 300 bytes, which is not enough for a 
> > > 512-byte bulk packet.  I think you'd run into trouble trying to do any 
> > > serious bulk transfers on such a tight schedule.
> > 
> > Yes, you seem to be right.
> > 
> > I still think 4% is maybe enough for control traffic.
> 
> It should be.

Ok then.

At least devices could be start/stopped, and frankly if someone loads
the bus with two high-bandwidth isoc streams, there is no reason to
expect any bulk transfer to happen at all.

> > > > @@ -571,6 +579,14 @@ static int ehci_init(struct usb_hcd *hcd)
> > > >  	hcc_params = ehci_readl(ehci, &ehci->caps->hcc_params);
> > > >  
> > > >  	/*
> > > > +	 * tell user, if using non-standard (80% == 100 usec/uframe) bandwidth
> > > > +	 */
> > > > +	if (uframe_periodic_max != 100)
> > > > +		ehci_info(ehci, "using non-standard max periodic bandwith "
> > > > +				"(%u%% == %u usec/uframe)",
> > > > +				100*uframe_periodic_max/125, uframe_periodic_max);
> > > > +
> > > > +	/*
> > > 
> > > Check for invalid values.  This should never be less than 100 or 
> > > greater than 125.
> > 
> > Ok. By the way, why should we limit it to be not less than 100?
> > Likewise, a user who knows exactly what he/she is doing could limit
> > periodic bandwidth to be less than 80% required by USB specification.
> 
> What's the point?  If you want to use less than 80% of your bandwidth 
> for periodic transfers, go ahead and do so.  You don't need to change 
> the limit.

I though it would be good for generality -- i.e. if someone wants to
limit maximum isoc bandwidth to say 50% so that would never be
overallocated by that limit that would be handy.

But I agree - it's a bit artificial, so in updated patch I've left what
you originally suggested to be 100 <= uframe_periodic_max < 125 (ommitting =125).


Thanks,
Kirill
--
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/