[openib-general] IPoIB Loading and Starting

[Michael Krause]

At 08:36 AM 9/27/2004, Roland Dreier wrote:
>     Michael> I don't follow why this is cosmetic.  The SM will
>     Michael> configure whatever number of P_Key per port (CA or
>     Michael> switch) that it desires.  IPoverIB does not and should
>     Michael> not care about this.  IPoverIB should probe the SM/SA to
>     Michael> determine what and how many P_Key it should use.  It
>     Michael> should then establish unique interfaces for each P_Key.
>     Michael> This is no different than what is done for 802.1Q where a
>     Michael> separate driver instance exists per tag.  This was our
>     Michael> intent when we wrote the specification.
>
>As far as I know the SM doesn't know anything about IPoIB.  What
>information can the IPoIB driver get from the SM/SA beyond what P_Keys
>are assigned to its local ports?  (And this is already available from
>the local P_Key table)

The SM only knows what it configures in each port.  The SA is responsible 
for service management and it works with the SM to map a given service to a 
P_Key.  The SA also sets up the all node multicast group.  IPoverIB joins 
this group in order to issue ARP/ND messages and therefore automatically 
discovers the P_Key to use.  IPoverIB is required to inquire what groups 
are available and optionally set up event notification to be informed when 
groups are added for its particular service.  This eliminates the need for 
local P_Key management.

>By the way, it's interesting that you mention 802.1q.  The Linux 
>implementation of VLAN tagging requires a userspace program (vlanconfig) 
>to be run to create tagged interfaces.

In general, the IPoverIB driver should treat each new all-nodes multicast 
group with a unique P_Key as a virtual hot-plug event (this was our intent 
both within the IETF and in the IBTA).  This should be linked into whatever 
OS management interfaces are required allowing ifconfig / dev file creation 
/ etc. to be executed.  This is orthogonal to P_Key management which was 
the original point of debate earlier in this string.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20040927/90899363/attachment.html>