Per your example, what shall be the fate of a pocket that matches PMR1 but
doesn't NOT match PMR2 ?
Where should those packets go ? What priority should they be given ?
That is why there is a CoS assigned to every packet at every stage in the
classifier - so that it has where to go if it fails to match all of the rules
that were applied to it.
You could picture every PMR as a decision diamond in a flow chart, and every
arrow for both outcomes of a decision is a CoS, where the value is unchanged
when a decision is "no match".
{ Leo }
On Oct 24, 2014, at 2:07 AM, Radu-Andrei Bulie
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I have some questions regarding the classifier API.
When creating cascading pmrs, cos parameter is specified - see odp_cos_pmr_cos
A cos is basically (as stated in the classifier doc) a target for packets.
One of the elements attached to the cos is the frame queue (or a group of frame
queues).
When linking a pmr by other pmr the odp_cos_pmr_cos function is used.
In this case, packets that match let's say pmr1 will go to cos1 then to pmr2
and if there is a match
they will go to cos2. (pmr1 -->cos1 -->pmr2->cos2)
Why do we need the cos in this situation? Do we make an enqueue to cos1 then
from this enqueue we go to pmr2?(I think that classification should be done
directly without the scheduler intervention)
Or the cos is seen just as a logical element to link pmr1 with pmr2? In this
case what is the sense of the cos' frame queue if it is not used? Why not
link the pmrs directly without any cos?
If there is a cascading chain (consider the above one as a snippet in a longer
chain) what happens if the packets arrive to pmr2 but there is no match with
it.? They will be dropped?
Regards,
Radu
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
