[IBAL]path records pkey issue. was: [ofw] what's up with the OFA Windows project?

[chas williams - CONTRACTOR]

In message <C07C40DB2364324799506DE8FF12F8D85960A9 at EPEXCH1.qlogic.org>,"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?