>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 _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
