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

Re: "real" ingres implementation





On Sat, 4 Nov 2000, Werner Almesberger wrote:

> jamal wrote:
> > PS:- Werner, maybe we can add an action "mark" to the policer?
> 
> Argl, you mean changing the DS field ?  I could agree with a
> "set tc_index" part there, or maybe an extension to dsmark to
> use some default tc_index also in other cases than TC_POLICE_UNSPEC
> or default.
> 

Would be rather awkward to do on ingress. You will have to default to a
timer to kick things ... and then the timer granularity becomes an issue
etc.

You know something like what CISCO (and a lot of other vendors) do:
"Set precedence"
in our case this would be set DSCP_or_ECN 
We would need to have or this with something else eg
	set_DSCP_or_ECN | OK

[http://www.cisco.com/univercd/cc/td/doc/product/
software/ios111/cc111/car.htm#10549]

I realize this is in conflict with what dsmark does on egress and in fact
is redundant; we need to resolve it though.

> Actually, what I'd really like to have is a struct/vector of values
> selected by the classification. Then, any further action could be
> taken based on this. But implementing this efficiently needs a major
> infrastructure overhaul ...
> 

Major, major overhaul. 
I know you've been saying this for a while, we should definetely revist
for 2.5. I have some interesting ideas when we get there.

> > This will be a work-conserving scheme (as opposed to dsmark)
> 
> Last time I checked, dsmark was work-conserving ;-)

You are right.
I guess it depends on what's inside it ;-> For a FIFO yes. 
Sorry, the efcbq is the image that keeps popping up in my head
everytime;->

cheers,
jamal