Skip to content

ibv_query_port()

Contents

5.00 avg. rating (97% score) - 1 vote
int ibv_query_port(struct ibv_context *context, uint8_t port_num,
                   struct ibv_port_attr *port_attr);

Description

ibv_query_port() returns the attributes of a port of an RDMA device context.

Here is the full description of struct ibv_port_attr:

Name Protocol Description
state IB/IBoE/iWARP The logical port state. It can be one of the following enumerated values:

  • IBV_PORT_NOP - Reserved value, which shouldn't be observed
  • IBV_PORT_DOWN - Logical link is down. The physical link of the port isn't up. In this state, the link layer discards all packets presented to it for transmission
  • IBV_PORT_INIT - Logical link is Initializing. The physical link of the port is up, but the SM haven't yet configured the logical link. In this state, the link layer can only receive and transmit SMPs and flow control link packets, other types of packets presented to it for transmission are discarded
  • IBV_PORT_ARMED - Logical link is Armed. The physical link of the port is up, but the SM haven't yet fully configured the logical link. In this state, the link layer can receive and transmit SMPs and flow control link packets, other types of packets can be received, but discards non SMP packets for sending
  • IBV_PORT_ACTIVE - Logical link is Active. The link layer can transmit and receive all packet types
  • IBV_PORT_ACTIVE_DEFER - Logical link is in Active Deferred. The logical link was Active, but the physical link suffered from a failure. 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 Maximum MTU supported by this port. It can be one of the following enumerated values:

  • IBV_MTU_256 - MTU is 256 bytes
  • IBV_MTU_512 - MTU is 512 bytes
  • IBV_MTU_1024 - MTU is 1024 bytes
  • IBV_MTU_2048 - MTU is 2048 bytes
  • IBV_MTU_4096 - MTU is 4096 bytes
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
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:

  • 1 << 1   - Indication that the SM that manages the subnet sending the packets from this port
  • 1 << 10 - Indication that there is an SM which isn't active in this port
  • 1 << 17 - Indication that an SNMP Tunneling agent is listening on this port
  • 1 << 19 - Indication that a Device Management agent is listening on this port
  • 1 << 20 - Indication that a Vendor specific agent is listening on this port
  • 1 << 25 - Indication that this port capable of generating the IBV_EVENT_CLIENT_REREGISTER asynchronous event
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:

  • 1 - 1 VL: VL0
  • 2 - 2 VLs: VL0, VL1
  • 3 - 4 VLs: VL0 - VL3
  • 4 - 8 VLs: VL0 - VL7
  • 5 - 15 VLs: VL0 - VL14
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: 4.096*2^{SubnetTimeOut}
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:

  • 1 - 1x
  • 2 - 4x
  • 4 - 8x
  • 8 - 12x
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:

  • 1 - 2.5 Gbps
  • 2 - 5.0 Gbps
  • 4 - 10.0 Gbps
  • 8 - 10.0 Gbps
  • 16 - 14.0 Gbps
  • 32 - 25.0 Gbps
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:

  • 1 - Sleep: The port drives its output to quiescent levels and does not respond to received data. In this state, the link is deactivated  without powering off the port
  • 2 - Polling: The port transmits training sequences and responds to receive training sequences.
  • 3 - Disabled: The port drives its output to quiescent levels and does not respond to receive data
  • 4 - PortConfigurationTraining: Both transmitter and receive active and the port is attempting to configure and transition to the LinkUp state
  • 5 - LinkUp: The port is available to send and receive packets
  • 6 - LinkErrorRecovery: Port attempts to re-synchronize the link and return it to normal operation
  • 7 - Phytest: Port allows the transmitter and received circuitry to be tested by external test equipment for compliance with the transmitter and receiver specifications
link_layer IB/IBoE/iWARP The link layer protocol used by this port. It can be one of the following enumerated values:

  • IBV_LINK_LAYER_UNSPECIFIED - Legacy value, used to indicate that the link layer protocol is InfiniBand
  • IBV_LINK_LAYER_INFINIBAND - Link layer protocol is InfiniBand
  • IBV_LINK_LAYER_ETHERNET - Link layer protocol is Ethernet, thus IBoE (or RoCE) can be used
* 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:

struct ibv_port_attr port_attr;
int port_num = 1;
 
rc = ibv_query_port(ctx, port_num, &port_attr);
if (rc) {
	fprintf(stderr, "Error, failed to query port %d attributes in device '%s'\n",
		port_num, ibv_get_device_name(ctx->device));
	return -1;
}

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).

Share Our Posts

Share this post through social bookmarks.

  • Delicious
  • Digg
  • Newsvine
  • RSS
  • StumbleUpon
  • Technorati

Comments

Tell us what do you think.

  1. test says: March 22, 2013

    if the parameter IBV_MTU_4096 means infinitiband block's max size is 4096?

    • Dotan Barak says: March 22, 2013

      Hi.

      The enumerated value IBV_MTU_4096 means that this ports support sending/receiving packets of 4096 bytes. This is the maximum size of a UD message that this port can send/receive.

      Thanks
      Dotan

  2. Frank says: January 23, 2014

    Hi! I'm try compile show_port_attr.c in Visual Studio 2010 ( WinOF 4.6, OFED_SDK 3.2), but ibv_query_port corrupt stack of port_attr... Please help me...

    • Dotan Barak says: January 23, 2014

      Hi Frank.

      Can you please share the code with me, so I'll try to help you?

      Thanks
      Dotan

  3. Frank says: January 30, 2014

    Hi Dotan. I compiled your example http://www.rdmamojo.com/wp-content/uploads/2012/07/show_port_attr.c But in Mellanox WinOF 4.6, driver returned incorrect structure "ibv_port_attr" in get_query_port. I deleted WinOF, installed only OFED3.2 for windows( from openfabrics.org) and everything worked correctly

    • Dotan Barak says: January 30, 2014

      Hi Frank.

      This source code was developed and tested with Linux OFED and not with the Mellanox WinOF.

      I'm quite convinces that it will work with any other flavor of Unix/Linux which supports libibverbs. It wasn't intended so work with Windows (sorry).

      For Windows, it is highly recommended to work with ND.

      Thanks
      Dotan
      (I don't know if it will work in

Add a Comment

This comment will be moderated; answer may be provided within 14 days.

Time limit is exhausted. Please reload CAPTCHA.