Partition Key (P_Key)
Definition of a Partition
A partition is defined as a collection of CA, router, and switch ports that are permitted to communicate with one another. A port may be a member of multiple partitions simultaneously.
Who Enrolls a Port in a Partition?
Refer to Figure 16-1 on page 322. A partition is represented by a 15-bit partition ID. Theoretically, this permits up to 32K partitions to be set up. Partition values assigned to a port are stored in the port's P_KeyTable attribute. The attribute consists of a series of P_Key entries.
Figure 16-1. P_Key Format
One or more P_Keys are assigned to a port by the subnet's PM (Partition Manager). The PM is typically implemented as a subset of the Master SM. The P_KeyTable attribute is read and written using SMPs issued by the PM.
A Port Can Be a Member of Multiple Partitions
The size of a port's P_KeyTable attribute (and therefore the number of P_Keys which can be assigned to the port) is device design-specific (but its maximum possible size is 32K entries). The actual size of the P_KeyTable attribute implemented for each port on a CA or router and for the switch management port is found in the NodeInfo.PartitionCap attribute element. If a switch implements the optional P_KeyTable attribute at each external port, the table size is found in the SwitchInfo.PartitionEnforcementCap attribute element. For a detailed description of the P_KeyTable, refer to “P_KeyTable Attribute” on page 837).
Which P_Key Is Inserted in Packets and Checked?
For RC, UC, and UD
General
When using the RC, UC, or UD service types, the QP is connected to one of the HCA's ports (during QP set up). When the QP is created and then initialized (using the Modify QP verb), the QP's Context is configured with:
- The HCA port number that the QP uses to send and receive packets
- and the index (i.e., a selector) into the respective port's P_KeyTable. The index is referred to as the P_Key Index.
On Packet Output
The QP inserts the port P_Key selected by the QP's P_Key index into the BTH:P_Key field of all outgoing packets that it generates.
On Packet Receipt
On packet receipt, the port forwards the packet to the RQ Logic of the target QP indicated in the packet's BTH:DestQP field. The QP's RQ Logic checks the packet's P_Key against the port P_Key selected by the QP's P_Key index value.
For RD
When using the RD service type, rather than the QP being connected to an HCA port, it is the EEC that is connected to it. Therefore, it is the EEC that is configured with:
The HCA port number that the EEC uses to send and receive packets,
and the P_Key Index into the respective port's P_KeyTable.
The EEC inserts the port P_Key selected by the EEC's P_Key Index into the BTH:P_Key field of all outgoing packets it generates, as well as checking the P_Key in all incoming packets against it.
QP0 Is a Member of All Partitions
QP0, a port's Subnet Management Interface (SMI), is a member of all partitions and therefore does not check an incoming packet's P_Key. SMPs sent by a port's SMI may have any P_Key (the specification does say, however, that the default P_Key is used by convention; the default P_Keys are discussed in “P_KeyTable May or May Not Be in NV Memory” on page 323).
QP1 Is Also a Member of All Partitions, but...
QP1, a port's General Services Interface (GSI), is a member of all partitions, but it handles P_Key checking a little differently than QP0 (the SMI). On packet receipt, the P_Key need only match any entry in the port's P_KeyTable. The QP's P_Key Index is not used to select a specific table entry to compare against. When QP1 is sending a packet, it can use any P_Key value from its output port's P_KeyTable.
Raw QPs Don't Use Partitions
IPv6 and EtherType QPs do not use P_Keys at all.
P_Key Format and the Membership Types
Refer to Figure 16-1 on page 322. Each P_Key entry in a port's P_KeyTable is a 16-bit value:
The lower 15 bits is the actual P_Key value representing a partition the port belongs to.
The upper most bit is the membership type bit:
- 0 = the port has limited membership in the partition.
- 1 = the port has full membership in the partition.
Table 16-2 on this page defines the rules that define whether or not the target port will accept a packet.
| Source Port Membership Type | Destination Port Membership Type | Access Permitted? |
|---|---|---|
| Limited | Limited | No |
| Limited | Full | Yes |
| Full | Limited | Yes |
| Full | Full | Yes |
Switch Port 0 Implements a Partition Table
The switch management port (port 0) implements the P_KeyTable attribute to validate incoming GMPs (see “QP1 Is Also a Member of All Partitions, but...” on page 320).
Switch and Router May Implement Partition Checking
If a switch or router implements optional, port-level P_Key enforcement, it can be configured to perform a P_Key check at:
the port a packet is received on,
the port it will be forwarded through,
or both.
The inbound and/or outbound port logic checks to see if the P_Key in the packet matches the P_Key of any destination port that can be reached moving in that direction through that port. If no port that can be reached via that path belongs to that partition, the packet is either silently dropped by the port or is deliberately corrupted and passed on towards its destination.
Assuming that the switch or router implements this optional feature, each of its ports implements the P_KeyTable attribute. A detailed description of the switch or router operation regarding P_Key validation can be found in “P_KeyTable Attribute” on page 837.
P_Key Validation
General
When an incoming packet reaches the destination port, the port's logic compares the P_Key in the incoming packet with its own P_Key (the one selected by the destination QP's or EEC's P_Key Index value). The incoming packet is not discarded if it passes the following two checks:
They are both members of the same partition (i.e., the lower 15 bits of the packet and destination port's P_Keys match).
If the packet passes the first check, the membership type of the packet and the port are compared (refer to Figure 16-1 on page 322 and Table 16-2 on page 321):
- If they both have limited membership in the partition, the destination port silently drops the packet.
- Otherwise, the packet is accepted.
Bad P_Key Trap and P_KeyViolations Counter
Optionally, each time an incoming packet is dropped due to a key match failure or a membership type failure, a Bad P_Key trap MAD can be sent to the SM and the PortInfo.P_KeyViolations counter can be incremented. More information on traps can be found in “Traps” on page 790.
P_KeyTable May or May Not Be in NV Memory
A port's P_KeyTable attribute may or may not be stored in NV memory (non-volatile memory). If it's not, then after startup:
Each port's P_KeyTable attribute must act as if it contains only one entry (entry 0) containing the default P_Key.
The default P_Key is assigned by the SM and is either:
- The default full-membership P_Key of FFFFh (note that bit 15 = 1, indicating full-membership), or
- the default limited-membership P_Key of 7FFFh (note that bit 15 = 0, indicating limited membership).