On 12/9/2015 11:26 AM, Hefty, Sean wrote: >>> I mean that the user needs to investigate why the fabric is not working >> out of box. >> >> My point is that an educated admin should _know_ to configure in these >> cases and that debug is only when things are broken not by default in >> these more complex cases. This means the limitations of the out of box >> approach needs to be explained in the docs. > > When IP addresses are used, the corresponding pkey is used. The issue this patch is addressing is the mapping of 'hostnames' to pkeys, as show in this ibacm_addr.cfg example: > > #Name device port pkey > cst-lin0 mlx4_0 1 default > cst-lin0-1 mlx4_0 1 default > cst-lin0-2 mlx4_0 2 default > > Currently, 'default' is hard-coded to a pkey of 0xffff. The intent is to define a better default value. Kaike has suggested this be the new default: > > 1. Find the first non-management full-member pkey; By "non-management full-member pkey", I think you mean "pkey which is other than a full member of default (0x7fff) partition". > 2. If it fails, find pkey 0xffff; To me, finding pkey 0xffff is better/safer than assuming it's in index 0 although it's likely there. > 3. If pkey 0xffff is not available, use the first pkey. > > Is there better alternative for what default should be? Order of 1 and 2 depends on use models for full default partition and other partitions. Reversing 1 and 2 (full default partition first) would handle the most common use models and handles Jason's case. The only common case that I'm aware of where that might fall down is in the virtualized case. I'm not sure what policy is best there and would need to think about that scenario some more (and there is more fundamental issue with ACM in those environments). > Jason was suggesting use pkey[0], which seems less robust in theory, but is simple and may cover the vast majority of real use cases. Seems less robust to me too. > The fewer cases where manual configuration is necessary, the fewer emails I receive, and the better off I am. :) Understood. -- Hal > - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
