[ofw] [PATCH] mlx/mthca: report active width as part of portattributes

Sean Hefty sean.hefty at intel.com
Thu Aug 13 09:21:01 PDT 2009


>It's OK as a quick-n-dirty solution.
>The question is why it should be that quick.

Because the structure is shared between user space and the kernel, I don't
believe this is worth breaking the application level ABI to fix this.  Trying to
define separate structures between the kernel and user space is fairly invasive.

We can rename the field to clarify the contents, which maintains the ABI, but
breaks the API.  Since the field is currently uninitialized, we can define it to
whatever is needed.

I choose the option of maintaining both the ABI and API.  The intent wasn't a
quick-n-dirty solution.

>We can change QUERY_CA API for the next release so it will contain some
>other worthy values (without misusing the field).
>You can see them in 'vstat -m' output:
>
>	Supported_link_speed=2.5 Gbps (1), 5.0 Gbps (2),
>      Supported_link_width=1x (1), 4x (2),
>      Enabled_link_speed=2.5 Gbps (1), 5.0 Gbps (2),
>      Enabled_link_width=1x (1), 4x (2),
>	Active_link_speed=5.0 Gbps (2),
>	Active_link_width=4x (2),

I saw that vstat gave this output.  I wanted to avoid using a MAD interface in
order to find the current active width.  A MAD interface seems fine for IB
diagnostic utilities.

I'm developing an application that interfaces to libibverbs and uses this field
from struct ibv_port_attr.  The port attribute fields that are needed are:

max_mtu, active_mtu, active_width, active_speed

For non-diagnostic applications, only the active fields seem useful, but
ibv_devinfo will report all of these.  For max_mtu, I simply set that to the
active_mtu.  active_speed was correctly being reported.  This left active_width
as the only missing field of interest.

Reporting other fields can be done, but they will not be reported by either
winverbs or libibverbs.

- Sean




More information about the ofw mailing list