The system statically allocates ingress TCAM resources for use by SAP ingress QoS classification, SAP ingress access control lists (ACLs), identifying and sending CFM OAM packets to CPU for local processing, and so on. The resource allocation is not user-configurable. With the introduction of new capabilities such as IPv6 classification, UP MEP support, and G8032-fast-flood, the static allocation of resources by software does not meet requirements of customer who need to use different features.
The user can allocate a fixed amount of resources per system for QoS, ACLs, CFM/Y.1731 MEPs, and other features. Of these, some parameters are boot-time and others are run-time. A change in the current value of the parameter that is designated boot-time needs a reboot of the node before the new value takes effect. Change in the current value of the parameter that is designated run-time takes effect immediately if the software determines resources are available for use to accommodate the change.
During bootup, the system reads the resource profile parameters and allocates resources to features in the order they appear in the configuration file.
Because resources are shared, the user must ensure that the sum total of such resources does not exceed the limit supported by the IMM or node. If the system determines that it cannot allocate the requested resources, the feature is disabled. For example, if the system determines that it cannot allocate resources for g8032-fast-flood, it disables the feature from use and G8032 eth-rings will not be able to use fast-flood mechanisms). Another example is the case where the system determines that it cannot allocate resources for IPv4-based SAP Ingress ACL classification, the system will not allow users to use IPv4-based SAP ingress ACL classification feature and fails the configuration when it comes upon the first SAP in the configuration file that uses an IPv4-based SAP ingress ACL policy.
For boot-time parameters, such as g8032-fast-flood-enable, the user must ensure that the configured services match the resources allocated. If the system determines that it cannot allocate resources to services, it fails the configuration file at the first instance where it encounters a command to which resources cannot be allocated. The available resources can be allocated to different features.
For ACL and QoS resources, the user has the option to allocate resources to limit usage per feature, regardless of the match criteria used. The sum of all resources used for different SAP ingress classification match-criteria is limited by the amount of resources allocated for SAP ingress classification. The user can also allocate resources by specific match criteria. The user can enable any supported match criteria and associate a fixed amount of resources with each match criteria in fixed sizes; the chunk size is dependent on the platform.
The system allocates resources based on the order of appearance in the configuration file, and fails any match criteria if the system does not have any more resources to allocate. In addition, the max keyword can be used to indicate that the system needs to allocate resources when they are first required, as long as the maximum amount of resources allocated for that feature is not exceeded or the maximum amount of resources available in the system is not exceeded. The 7210 SAS platforms allocate resources to each feature and match-criteria in fixed-size chunks.
The no form of the command disables the use of corresponding match criteria. During runtime, the command succeeds, if no SAPs are currently using the criteria. Similarly, reduction of resources from the current value to a lower value succeeds, if no SAPs are currently using the criteria.
If the system successfully runs the no command, it frees up resources used by the chunk or slice and make the resources, or the entire chunk/slice, available for use by other features. Before deallocating resources, the software checks if a service object is using the resource and fails the command if the object is in use. If resources are in use, they can be freed up by deleting a SAP, removing a policy association with a SAP, deleting a MEP, and so on. Some commands under the system resource-profile context do not take effect immediately and require a system reboot before the change occurs and resources are freed. The following is the handling of freed resources:
If some entries in a slice are freed, they are made available for use by other SAPs using the same feature to which the chunk is allocated.
If an entire chunk is freed, it is returned to the system free pool for possible use by other features.
The no form of the commands that are designated as boot-time does not take effect immediately. It takes effect after the reboot. Before reboot, it is the user’s responsibility to free up resources required for use by the feature that has been enabled to take effect after the reboot. Not doing so results in failure when the configuration file is executed on boot up.
See the CLI and feature description chapters in the appropriate 7210 SAS platform user guide for more information about CLI commands and features that use system resource allocation.