On Mon, Dec 15, 2008 at 11:25 AM, Mike Heinz <[email protected]> wrote: > As long as any API change permits interoperation with spec-compliant > SMs, that's fine.
That's exactly the idea; Allow for both (spec compliant and enhanced) modes of operation. -- Hal >At the moment, the infinibanddiags tool, saquery, will > fail when looking for path records on SMs other than OpenSM; that was > the problem that actually sent me down this path. > > -- > Michael Heinz > Principal Engineer, Qlogic Corporation > King of Prussia, Pennsylvania > > -----Original Message----- > From: Hal Rosenstock [mailto:[email protected]] > Sent: Monday, December 15, 2008 10:54 AM > To: Mike Heinz > Cc: [email protected] > Subject: Re: [ofa-general] Bugs in opensm/libvendor > > Mike, > > On Mon, Dec 15, 2008 at 10:41 AM, Mike Heinz <[email protected]> > wrote: >> Hal, >> >> I could be wrong, but as I understand it, this function does not >> permit the user to request more than one path. The API takes a query >> request which contains pair of lids or guids, but does not have a >> field for specifying the number of paths. > > You're right; the path requests do not currently support num_paths > unlike multipath requests. But there is reliance on this "feature". So > the current API needs enhancement to support this IMO to preserve > backward compatibility. > >> -- >> Michael Heinz >> Principal Engineer, Qlogic Corporation King of Prussia, Pennsylvania >> >> -----Original Message----- >> From: Hal Rosenstock [mailto:[email protected]] >> Sent: Monday, December 15, 2008 10:31 AM >> To: Mike Heinz >> Cc: [email protected]; John Russo >> Subject: Re: [ofa-general] Bugs in opensm/libvendor >> >> On Wed, Dec 10, 2008 at 1:31 PM, Mike Heinz <[email protected]> >> wrote: >>> While experimenting with the APIs in opensm/libvendor, > > In tree or out of tree application(s) ? > >> I was unable to >> >>> get the path record queries to work. Reviewing the error logs from >>> the >> >>> SM, >> >> Which SM(s) ? > > Which SM(s) ? > > -- Hal > >>> I discovered that the APIs were not setting the required num_path >> field. >>> Here's the fix: >> >> The approach used breaks backward compatibility which IMO should be >> preserved. >> I think a better approach is as follows: >> 1. Set num_paths in the application(s) as desired 2. In the library, >> check for num_paths 0 or not. If not, then set the numbpath compmask >> bit. >> >> -- Hal >> >>> --- osm_vendor_ibumad_sa.bak 2008-12-10 13:21:22.000000000 -0500 >>> +++ osm_vendor_ibumad_sa.c 2008-12-10 13:24:42.000000000 -0500 >>> @@ -615,7 +615,7 @@ >>> sa_mad_data.attr_offset = >>> ib_get_attr_offset(sizeof(ib_path_rec_t)); >>> sa_mad_data.comp_mask = >>> - (IB_PR_COMPMASK_DGID | IB_PR_COMPMASK_SGID); >>> + (IB_PR_COMPMASK_DGID | IB_PR_COMPMASK_SGID | >>> IB_PR_COMPMASK_NUMBPATH); >>> sa_mad_data.p_attr = &path_rec; >>> ib_gid_set_default(&path_rec.dgid, >>> ((osmv_guid_pair_t *) >>> (p_query_req-> @@ -625,6 +625,7 @@ >>> ((osmv_guid_pair_t *) >> (p_query_req-> >>> >> p_query_input))-> >>> src_guid); >>> + path_rec.num_path = 1; >>> break; >>> >>> case OSMV_QUERY_PATH_REC_BY_GIDS: >>> @@ -634,7 +635,7 @@ >>> sa_mad_data.attr_offset = >>> ib_get_attr_offset(sizeof(ib_path_rec_t)); >>> sa_mad_data.comp_mask = >>> - (IB_PR_COMPMASK_DGID | IB_PR_COMPMASK_SGID); >>> + (IB_PR_COMPMASK_DGID | IB_PR_COMPMASK_SGID | >>> IB_PR_COMPMASK_NUMBPATH); >>> sa_mad_data.p_attr = &path_rec; >>> memcpy(&path_rec.dgid, >>> &((osmv_gid_pair_t *) >>> (p_query_req->p_query_input))-> @@ -642,6 +643,7 @@ >>> memcpy(&path_rec.sgid, >>> &((osmv_gid_pair_t *) >> (p_query_req->p_query_input))-> >>> src_gid, sizeof(ib_gid_t)); >>> + path_rec.num_path = 1; >>> break; >>> >>> case OSMV_QUERY_PATH_REC_BY_LIDS: >>> @@ -652,13 +654,14 @@ >>> sa_mad_data.attr_offset = >>> ib_get_attr_offset(sizeof(ib_path_rec_t)); >>> sa_mad_data.comp_mask = >>> - (IB_PR_COMPMASK_DLID | IB_PR_COMPMASK_SLID); >>> + (IB_PR_COMPMASK_DLID | IB_PR_COMPMASK_SLID | >>> IB_PR_COMPMASK_NUMBPATH); >>> sa_mad_data.p_attr = &path_rec; >>> path_rec.dlid = >>> ((osmv_lid_pair_t *) >> (p_query_req->p_query_input))-> >>> dest_lid; >>> path_rec.slid = >>> ((osmv_lid_pair_t *) >>> (p_query_req->p_query_input))->src_lid; >>> + path_rec.num_path = 1; >>> break; >>> >>> case OSMV_QUERY_UD_MULTICAST_SET: >>> --- osm_vendor_mlx_sa.bak 2008-12-10 13:21:10.000000000 -0500 >>> +++ osm_vendor_mlx_sa.c 2008-12-10 13:24:07.000000000 -0500 >>> @@ -743,7 +743,7 @@ >>> sa_mad_data.attr_offset = >>> ib_get_attr_offset(sizeof(ib_path_rec_t)); >>> sa_mad_data.comp_mask = >>> - (IB_PR_COMPMASK_DGID | IB_PR_COMPMASK_SGID); >>> + (IB_PR_COMPMASK_DGID | IB_PR_COMPMASK_SGID | >>> IB_PR_COMPMASK_NUMBPATH); >>> sa_mad_data.p_attr = &path_rec; >>> ib_gid_set_default(&path_rec.dgid, >>> ((osmv_guid_pair_t *) >>> (p_query_req-> @@ -753,6 +753,7 @@ >>> ((osmv_guid_pair_t *) >> (p_query_req-> >>> >> p_query_input))-> >>> src_guid); >>> + path_rec.num_path = 1; >>> break; >>> >>> case OSMV_QUERY_PATH_REC_BY_GIDS: >>> @@ -763,7 +764,7 @@ >>> sa_mad_data.attr_offset = >>> ib_get_attr_offset(sizeof(ib_path_rec_t)); >>> sa_mad_data.comp_mask = >>> - (IB_PR_COMPMASK_DGID | IB_PR_COMPMASK_SGID); >>> + (IB_PR_COMPMASK_DGID | IB_PR_COMPMASK_SGID | >>> IB_PR_COMPMASK_NUMBPATH); >>> sa_mad_data.p_attr = &path_rec; >>> memcpy(&path_rec.dgid, >>> &((osmv_gid_pair_t *) >>> (p_query_req->p_query_input))-> @@ -771,6 +772,7 @@ >>> memcpy(&path_rec.sgid, >>> &((osmv_gid_pair_t *) >> (p_query_req->p_query_input))-> >>> src_gid, sizeof(ib_gid_t)); >>> + path_rec.num_path = 1; >>> break; >>> >>> case OSMV_QUERY_PATH_REC_BY_LIDS: >>> @@ -789,6 +791,7 @@ >>> dest_lid; >>> path_rec.slid = >>> ((osmv_lid_pair_t *) >>> (p_query_req->p_query_input))->src_lid; >>> + path_rec.num_path = 1; >>> break; >>> >>> case OSMV_QUERY_UD_MULTICAST_SET: >>> >>> -- >>> Michael Heinz >>> Principal Engineer, Qlogic Corporation King of Prussia, Pennsylvania >>> >>> _______________________________________________ >>> general mailing list >>> [email protected] >>> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general >>> >>> To unsubscribe, please visit >>> http://openib.org/mailman/listinfo/openib-general >>> >> > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
