[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "real" ingres implementation

To: jamal <hadi@cyberus.ca>
Subject: Re: "real" ingres implementation
From: Werner Almesberger <Werner.Almesberger@epfl.ch>
Date: Mon, 6 Nov 2000 09:50:27 +0100
Cc: linux-diffserv@lrc.di.epfl.ch
Delivery-date: Mon, 06 Nov 2000 11:27:12 +0200
Envelope-to: archive@lists.atm.tut.fi
In-Reply-To: <Pine.GSO.4.20.0011052115270.2665-100000@shell.cyberus.ca>; from hadi@cyberus.ca on Sun, Nov 05, 2000 at 09:18:27PM -0500
References: <20001105195227.Y3223@almesberger.net> <Pine.GSO.4.20.0011052115270.2665-100000@shell.cyberus.ca>
Sender: owner-linux-diffserv@lrc.epfl.ch

jamal wrote:
> for forwarding path, absolutely. For the local destination path, you
> brought up ECN ;-> and so i was just thinking out loudly

Oh, I see ... yes, you have a point there. For bastard qdiscs (*) like
dsmark, this makes sense indeed, ugly as it is ...

(* work-conserving isn't enough, because for local delivery, you don't
   have useful backpressure, so it really has to be a qdisc that neither
   delays nor depends on backpressure. This leaves ingress, dsmark ...
   and maybe sch_atm - now *that* would be dirty ;-)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

Follow-Ups:
- Re: "real" ingres implementation
  - From: jamal

References:
- Re: "real" ingres implementation
  - From: Werner Almesberger
- Re: "real" ingres implementation
  - From: jamal

Prev by Date: Re: "real" ingres implementation
Next by Date: Re: "real" ingres implementation
Previous by thread: Re: "real" ingres implementation
Next by thread: Re: "real" ingres implementation
Index(es):
- Date
- Thread