[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