|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Alan Cox <alan@cymru.net> To: smurf@smurf.noris.de (Matthias Urlichs) Date: Fri, 19 Apr 1996 11:11:26 +0100 (BST) Cc: alan@cymru.net, smurf@smurf.noris.de, linux-net@vger.rutgers.edu In-Reply-To: <96Apr19.112706+0100met_dst.2218-655+18@work.smurf.noris.de> from "Matthias Urlichs" at Apr 19, 96 11:27:05 am > The customer pays for a connection limited to bandwidth X, and that's what > they'll get -- something that behaves exactly like it would if it was > behind a X-bps serial line (or whatever, doesn't matter), i.e. a small > queue which delays processing until enough time has elapsed for the > previous packet to be "transmitted". This is fine so long as thats what you implement, including virtual prioritisation, and you try to avoid dropping bursts and sending bursts - ie the "sent 9600 bits this second flat out now drop the rest2 scheme. Doing the prioritising right ought I suppose to come out naturally if your driver becomes "ready" at the right moment and keeps packets on the dev_queue_xmit queues. > All standard IP interfaces (esp. PPP and SLIP) already do this, so doing > more of the same shouldn't be a problem. Sounds promising.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |