I think we should talk a little bit more on this issue. > here's one. we have two partitions, 0xffff and 0xfff2. this causes > some confusion with the pnp layer. when the pnp layer iterates the > nodes/paths to the hardware, the first path returned isnt always on > the default partition. if this path is given to srp, then srp > attempts to login to the storage on the non-default pkey.
I believe if SM returns path records with different pkeys it should mean host and a storage are both members of both partitions, and obtained paths are valid for this host. Then the consumer of path records (SRP initiator in our case) could validate what path has higher priority to use. > > this patch makes the pnp layer only return the default paths. With proposed patch all IOCs on the fabric will be visible only by hosts having default pkey in it's pkey table. For example, if IOC configured to have pkey1 only, then host on the same partition with pkey1 won't ever find this IOC, since it will be looking for it in default partition only. Thoughts? > > > > Index: trunk/core/al/kernel/al_ioc_pnp.c > > =================================================================== > > --- trunk/core/al/kernel/al_ioc_pnp.c (revision 775) > > +++ trunk/core/al/kernel/al_ioc_pnp.c (working copy) > > @@ -1569,13 +1569,15 @@ > > info.method = IB_MAD_METHOD_GETTABLE; > > info.attr_id = IB_MAD_ATTR_PATH_RECORD; > > info.attr_size = sizeof(ib_path_rec_t); > > - info.comp_mask = IB_PR_COMPMASK_SGID | IB_PR_COMPMASK_NUM_PATH; > > + info.comp_mask = IB_PR_COMPMASK_SGID | > > IB_PR_COMPMASK_NUM_PATH | > > +IB_PR_COMPMASK_PKEY; > > info.p_attr = &u.path_rec; > > > > cl_memclr( &u.path_rec, sizeof(ib_path_rec_t) ); > > ib_gid_set_default( &u.path_rec.sgid, p_svc->port_guid ); > > /* Request all the paths available, setting the > > reversible bit. */ > > u.path_rec.num_path = 0xFF; > > + /* Request only paths from the default partition */ > > + u.path_rec.pkey = cl_hton16(IB_DEFAULT_PKEY); > > > > query.pfn_query_cb = __path_rec_cb; > > > > _______________________________________________ > > ofw mailing list > > [email protected] > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw > > > _______________________________________________ > ofw mailing list > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
