On Wed, 2003-08-06 at 20:37, Martin A. Brown wrote: > : 2) Since the filters themselves are, as you say, stateless, then it > : sounds like a "policer" is a separate object that's being created at > : the same time as the filter. Is there any other way to create a > : "policer" object, or do they only exist when attached to filters? > > My understand is that the policers only exist attached to filters. They > are separate, but not able to be generated without a filter. I think > Stef's description isn't so bad....a policer is similar to a token bucket > filter (TBF) which is attached to a filter. I don't know what it looks > like inside the policing code, so I'll have to assume that this is > correct. From the outside of the black box, they are pretty much rate > limiters which you can attach to any "tc filter" command. >From what Stef says, the documentation on the TC_INDEX qdisc illuminates the use and structure of policers. I've looked TC_INDEX only very briefly. I mention this here only so that anyone else who is interested will have the pointer. > : When working with egress traffic control, can you attach policers > : to filters, > > Yes. > > : and how would they interact with the classes? > > When a new packet arrives on an output queue prior to outbound traffic > control (but after netfilter POSTROUTING), the packet will first traverse > the filters attached to qdisc 1:0 to learn of its destination flowid. > Here, you could have a number of different filters which classify and/or > reclassify the packet into different output classes/qdiscs. You could > optionally drop packets with a filter here, just as you could drop packets > with filters on the ingress qdisc. > > These policers will be VERB (executed? obeyed?) before the packet ever > enters the classes and sub-classes. OK - This is very interesting to me. I understand the mechanism whereby filters guide packets to the classes for which they are destined. That all makes sense. Based on what I've read here, it sounds like you can interpose a policer between the filter itself and the class to which it is directing packets. Given that classes already have access to the full range of qdiscs, with all their marvelous dials and knobs, interposing a policer seems superfluous. Have I misunderstood?
