Hi Roland,
Roland Dreier wrote:
Eitan> I thought the intent of the IB spec when defining P_Key
Eitan> index usage (and not P_Key value) was that the P_Key values
Eitan> would never need to be known above the driver level. To
Eitan> avoid exposing the P_Key values we could use P_Key index
Eitan> for creating the IPoIB interfaces.
Eitan> Does it make sense to work on a patch that would setup
Eitan> IPoIB interfaces by the P_Key index (and not by P_Key
Eitan> value)?
I don't see how this is feasible. The index that a particular P_Key
lands at is completely undetermined -- if two nodes wanted to talk on
partition 0x8001 say, how does one know which interface to use without
knowing the index of that P_Key?
OK, I get it. Actually the way IPoIB defines the broadcast group MGID exposes
P_Key anyway.
Eitan> Also I think the expected behavior for IPoIB should be that
Eitan> IPoIB "child" interfaces should be "automatically"
Eitan> initialized by the code that brings up the interface
Eitan> (ifconfig scripts). All valid IPoIB partitions (valid =
Eitan> have corresponding broadcast groups) should be
Eitan> initialized. By doing so we provide a centralized control
Eitan> of the partitions and their IPoIB interfaces through the
Eitan> SM.
Not sure if this is so. I may want a partition strictly for storage
traffic something like that, so it doesn't make sense to create an
IPoIB interface for that partition.
OpenSM provides this capability in the "partition policy":
Each partition is marked explicitly if to be used for IPoIB or not.
So through one file one could actually control the IPoIB interfaces
that will exist in the subnet.
My intent is to write some extension to ifup for IPoIB such that all sub
interfaces will be automatically started (based on pre-availability of IPoIB
broadcast MGID).
- R.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
