TOC
| Tutorial >> More Plugins |
TOC
|
A packet can be directed to the SPC by installing a filter that matches the packet and places the packet in one of the queues destined for the SPC (QIDs 8-127). This is true for both the ingress side and the egress side. Thus, the QID is not used to distinguish between the two sides. There is an intraport shim that is prepended to the AAL5 frame which encapsulates the IP packet. It is that shim that indicates whether the packet is from the ingress or the egress side. It has other fields that are used its progress through the different components of a port processor.
As shown in Fig. 1, it is possible for a packet to be processed by an SPC on both the ingress side and the egress side. After SPC processing on the ingress side, the packet is normally placed into one of the eight VOQs for transport to an output port. After SPC processing on the egress side, the packet is placed into FPX queue X+128 when the packet was placed into queue X for SPC processing. That is, if the packet is sent to the SPC on queue 8, it will be placed into FPX queue 136 (= 8 + 128) after SPC processing.
There are three other possible scenarios that do not fit into the description above:
By default, any packet created by a plugin will get reclassified after returning to the FPX. So, if a plugin creates a packet on the ingress side, the new packet will get classified and then placed into one of the eight VOQs. This situation is not unusual since we would expect that the FPX would have to decide where to send the new packet.
However, this situation may seem unusual at first. Again, by default, any packet created by a plugin (whether it was done on the ingress side or the egress side) will get reclassified after returning to the FPX. So, if a plugin creates a packet on the egress side, the new packet will get classified and then placed into one of the eight VOQs and not one of the egress queues with QID between 128 and 255. This occurs (by default) even though the packet was created on the egress side!
A little more thought would indicate that this is reasonable since a new packet could have an arbitrary IP header and therefore, its destination could be downstream from any of the output ports. This default behavior is supported by the buffer allocation routine in the SPC; i.e., allocating a new packet buffer using the msr_pkt_shim(...) function also sets the reclassify bit to ON in the intraport shim.
In some cases, it is possible that the user wants to forward a packet to a specific output port; i.e., without the FPX examining the packet header. This behavior can be implemented by setting the reclassify bit in the intraport shim to OFF and is true on both the ingress side and the egress side.
| Tutorial >> More Plugins |
TOC
|