描述
ibv_query_port()返回RDMA设备上下文(context)的端口的属性。
这是struct ibv_port_attr的完整描述:
Name | Protocol | Description |
---|---|---|
state | IB/IBoE/iWARP |
逻辑端口状态。它可以是下列枚举值之一:
(If the error will be recovered within a timeout, the logical link will return to IBV_PORT_ACTIVE, otherwise it will move to IBV_PORT_DOWN) |
max_mtu | IB/IBoE/iWARP |
该端口支持的最大MTU。它可以是下列枚举值之一:
|
active_mtu | IB/IBoE/iWARP |
Active maximum MTU enabled on this port to transmit and receive. It can be one of the following enumerated values which specified for max_mtu. This value specify the maximum message size that can be configured in UC/RC QPs and the maximum message size that an UD QP can transmit 在此端口上启用的最大活动MTU进行发送和接收。它可以是为max_mtu指定的以下枚举值之一。此值指定可以在UC / RC QP中配置的最大消息大小以及UD QP可以传输的最大消息大小 |
gid_tbl_len | IB/IBoE/iWARP | Length of the Source GID Table of this port |
port_cap_flags | IB/IBoE/iWARP | Port's supported capabilities as bitwise ORed of the following numeric values since those values aren't enumerated:
|
max_msg_sz | IB/IBoE/iWARP | Maximum message size supported by this port |
bad_pkey_cntr | IB/IBoE | Bad P_Key counter of the port, if supported by the device (IBV_DEVICE_BAD_PKEY_CNTR is set in dev_cap.device_cap_flags) |
qkey_viol_cntr | IB/IBoE | Q_Key violations packets of the port, if supported by the device (IBV_DEVICE_BAD_QKEY_CNTR is set in dev_cap.device_cap_flags) |
pkey_tbl_len | IB/IBoE*/iWARP* | Length of the partition table of this port |
lid | IB | The base LID of this port, valid only if state is IBV_PORT_ARMED or IBV_PORT_ACTIVE |
sm_lid | IB | The LID of the SM that manages this port |
lmc | IB | Port LID mask of this port (used in multipath), valid only if state is IBV_PORT_ARMED or IBV_PORT_ACTIVE |
max_vl_num | IB | The maximum number of VLs supported by this port. There isn't any enumeration of this value, and the numeric value can be one of the following:
|
sm_sl | IB | The SL of the SM that manages this port |
subnet_timeout | IB | Specifies the maximum expected subnet propagation delay, which depends upon the configuration of the switches, to reach any other port in the subnet and also used to determine the maximum rate which SubnTrap()s can be sent from this port. The duration of time is calculated based on: ![]() |
init_type_reply | IB | Value configured by the SM prior to changing the port to IBV_PORT_ACTIVE or IBV_PORT_ARMED state that indicates the type of initialization performed, if supported by the device (IBV_DEVICE_INIT_TYPE is set in dev_cap.device_cap_flags) |
active_width | IB/IBoE*/iWARP* | The active link width of this port. There isn't any enumeration of this value, and the numeric value can be one of the following:
|
active_speed | IB/IBoE*/iWARP* | The active link speed of this port. There isn't any enumeration of this value, and the numeric value can be one of the following:
|
phys_state | IB | The physical link status. There isn't any enumeration for this value, and the numeric value can be one of the following:
|
link_layer | IB/IBoE/iWARP | The link layer protocol used by this port. It can be one of the following enumerated values:
|
* supported, but not really relevant
Most of the port attributes, returned by ibv_query_port(), aren't constant and may be changed, mainly by the SM (in InfiniBand), or by the Hardware. It is highly recommended avoiding saving the result of this query, or to flush them when a new SM (re)configures the subnet.
Parameters
Name | Direction | Description |
---|---|---|
context | in | RDMA device context, that was returned from ibv_open_device() |
port_num | in | Port number to query, values can be [1..dev_cap.phys_port_cnt] |
port_attr | out | Port attributes |
Return Values
Value | Description |
---|---|
0 | On success |
errno | On failure |
EINVAL | port_num is invalid |
ENOMEM | Out of memory |
Examples
Query a port attributes:
|
show_port_attr.c
FAQs
I'm using iWarp/IBoE, do I need all of the values that ibv_query_port() returns?
No. Check the protocol columns, to understand which attributes are relevant for you.
I'm using IB, do I need all of the values that ibv_query_port() returns?
No. There are fields that you will use more often (such as state), some you may use when debugging problems (the counters) and some of them are informative for other services.
Calling every time to ibv_query_port() when I need a port attribute takes time, can I cache some of the attributes?
Actually, yes. The attributes, which indicates the port supported attributes (such as supported table length and capabilities) won't change, but others, which are configured by the SM, state and counters may change.
In InfiniBand, if you want, you can cache the returned structure and query it only when an unaffiliated asynchronous event occurred (this will be discussed later on in other posts).