On Thu, 2008-02-14 at 11:58 -0500, chas williams - CONTRACTOR wrote: > In message <[EMAIL PROTECTED]>,"Alex Es > trin" writes: > >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. > > > >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. > > i also dont think the sm query returns both paths on both partitions. > just the path that is the 'best' match. if it return both paths i > wouldnt have my problem. i would think picking the best partition to > use should be done at the application layer, not the discovery layer? > > it is true that the storage is a member of both partitions. but i dont > know of any storage targets that respond to a pkey other than 0xffff. > the linux ofed stack just ignores this problem completely and hardcodes > 0xffff when it creates a path between the client and the storage. > > > i was under the impression that you need to be a member of the default > partition in all cases?
Yes, but perhaps only as a limited rather than full member. > _______________________________________________ > 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
