netdev - explaining the math behind the buffering done in USB network drivers

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>] [day] [month] [year] [list]

Date:	Thu, 08 Nov 2012 18:35:07 +0100
From:	Oliver Neukum <oneukum@...e.de>
To:	Robert Bradley <robert.bradley1@...il.com>,
	Dave Taht <dave.taht@...il.com>,
	Jim Gettys <jg@...edesktop.org>, netdev@...r.kernel.org
Subject: explaining the math behind the buffering done in USB network drivers

Hi,

it is probably necessary to state the limitations of USB to understand
why we buffer as much data as we buffer. Basically the schedule on
the USB bus is set in stone for a period of 1ms(full speed). This means that a driver
has to have submitted to USB core enough data to fill _2_ such periods
at all times. Thus the schedule for the current period is filled up and the
host controller can seamlessly switch to the next period.
In addition the driver has to be ready to provide the data for the next period
as soon as one period is done.

Thus conceptually for USB we do tripple-buffering.
Few drivers actually express this logic internally. One usually calculates
a rough approximation, but this is the logic behind the thing.

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html