From: Oliver Neukum <oneukum@suse.de>
To: Robert Bradley <robert.bradley1@gmail.com>,
Dave Taht <dave.taht@gmail.com>, Jim Gettys <jg@freedesktop.org>,
netdev@vger.kernel.org
Subject: explaining the math behind the buffering done in USB network drivers
Date: Thu, 08 Nov 2012 18:35:07 +0100 [thread overview]
Message-ID: <1544921.F1ezT4niGW@linux-lqwf.site> (raw)
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
reply other threads:[~2012-11-08 17:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1544921.F1ezT4niGW@linux-lqwf.site \
--to=oneukum@suse.de \
--cc=dave.taht@gmail.com \
--cc=jg@freedesktop.org \
--cc=netdev@vger.kernel.org \
--cc=robert.bradley1@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox