[ofa-general] [PATCH] libibmad: added support for handling of BM (Baseboard management) MADs - FIXED

Hal Rosenstock hal.rosenstock at gmail.com
Thu Mar 19 06:17:11 PDT 2009


On Thu, Mar 19, 2009 at 7:19 AM, Itai Baz <itaib at mellanox.com> wrote:
> Hi Sasha,
>
> This patch adds support for handling of BM (Baseboard management) MADs.
> I Fixed all of your comments, and resbumit this patch with the fixes
>
> Thanks
>
> Signed-off-by: Itai Baz <itaib at mellanox.co.il>
> ---
>  libibmad/Makefile.am              |    3 +-
>  libibmad/include/infiniband/mad.h |   49 ++++++++++++++++
>  libibmad/src/bm.c                 |  110 +++++++++++++++++++++++++++++++++++++
>  libibmad/src/libibmad.map         |    1 +
>  libibmad/src/register.c           |    2 +
>  5 files changed, 164 insertions(+), 1 deletions(-)
>  create mode 100644 libibmad/src/bm.c
>
<snip...>

> diff --git a/libibmad/include/infiniband/mad.h b/libibmad/include/infiniband/mad.h
> index b8290a7..d643d3d 100644
> --- a/libibmad/include/infiniband/mad.h
> +++ b/libibmad/include/infiniband/mad.h

<snip...>

> @@ -661,6 +697,16 @@ typedef struct ib_vendor_call {
>        ib_rmpp_hdr_t rmpp;
>  } ib_vendor_call_t;
>
> +typedef struct ib_bm_call {
> +       unsigned method;
> +       unsigned attrid;
> +       unsigned mod;
> +       unsigned timeout;
> +       ib_rmpp_hdr_t rmpp;

Is RMPP supported by BM class ?

> +       uint64_t bkey;
> +} ib_bm_call_t;
> +
> +
>  #define IB_MIN_UCAST_LID       1
>  #define IB_MAX_UCAST_LID       (0xc000-1)
>  #define IB_MIN_MCAST_LID       0xc000

<snip...>

> diff --git a/libibmad/src/bm.c b/libibmad/src/bm.c
> new file mode 100644
> index 0000000..29e0a3e
> --- /dev/null
> +++ b/libibmad/src/bm.c
> @@ -0,0 +1,110 @@

<snip...>

> +static inline int
> +response_expected(int method)
> +{
> +       return method == IB_MAD_METHOD_GET ||
> +               method == IB_MAD_METHOD_SET ||
> +               method == IB_MAD_METHOD_TRAP;
> +}

Most BM attributes use send method and response is indicated via bit
in AM but that's on the responder rather than requester side.

> +
> +uint8_t *
> +bm_call_via(void *data, ib_portid_t *portid, ib_bm_call_t *call, struct ibmad_port *srcport)
> +{
> +       ib_rpc_t rpc = {0};
> +       int resp_expected;
> +       char data_with_bkey[IB_BM_BKEY_AND_DATA_SZ] = {0};
> +
> +       DEBUG("route %s data %p", portid2str(portid), data);
> +       if (portid->lid <= 0) {
> +               IBWARN("only lid routes are supported");
> +               return 0;
> +       }
> +
> +       resp_expected = response_expected(call->method);
> +
> +       rpc.mgtclass = IB_BOARD_MGMT_CLASS;
> +
> +       rpc.method = call->method;
> +       rpc.attr.id = call->attrid;
> +       rpc.attr.mod = call->mod;
> +       rpc.timeout = resp_expected ? call->timeout : 0;
> +       // send data and bkey
> +       rpc.datasz = IB_BM_BKEY_AND_DATA_SZ;
> +       rpc.dataoffs = IB_BM_BKEY_OFFS;
> +
> +       // copy data to a buffer which also includes the bkey
> +       *((uint64_t *) data_with_bkey) = htonll(call->bkey);
> +       memcpy(data_with_bkey + IB_BM_DATA_OFFS - IB_BM_BKEY_OFFS, data, IB_BM_DATA_SZ);
> +
> +       DEBUG("method 0x%x attr 0x%x mod 0x%x datasz %d off %d res_ex %d bkey 0x%08x%08x",
> +               rpc.method, rpc.attr.id, rpc.attr.mod,
> +               rpc.datasz, rpc.dataoffs, resp_expected,
> +               (int) (call->bkey >> 32), (int) call->bkey);
> +
> +       portid->qp = 1;
> +       if (!portid->qkey)
> +               portid->qkey = IB_DEFAULT_QP1_QKEY;
> +
> +       if (resp_expected) {
> +               mad_rpc_rmpp(srcport, &rpc, portid, 0, data_with_bkey);         /* FIXME: no RMPP for now */

Should this just be mad_rpc (no RMPP) ?

-- Hal

<snip...>



More information about the general mailing list