Subject: RE: [Ipoverib] BOOTP/DHCP chaddr field

From: Michael Krause <[email-masked]>
Date: Mon, 18 Mar 2002 05:57:28 -0800

At 07:03 AM 3/17/2002 -0600, Culley, Paul wrote:

>I think it's a stretch to use different QPs to build multiple
>"virtual" interfaces. P_Key is the perfect mechanism for that.
><prc> If there are multiple P_Keys in use for IPoIB on a single port
>(quite possible in my opinion), then they must be using different QPs.
>Only one P_Key to a QP, remember?

A partition defines the equivalent of a VLAN (802.1Q) which is in essence a 
virtual fabric.  A QP defines the "SAP" for an IP address for a given 
port.  There will be at least one QP per IP address (whether this is to the 
same or different IP subnet operating over the IB VLAN).  In addition, 
there may be multiple OS instances per port as well potentially 
differentiated by the LID or GID but this is implementation-specific.

Mike

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Al Hartmann <[email-masked]>
Date: Tue, 19 Mar 2002 09:13:33 -0600

Jerry Chu wrote:

>  I don't see the value
>  of providing multiple "virtual" interfaces on the same IB 
>  partition by 
>  using the same HCA,
>  same port, but only different QPs.

If an implementation associates QoS with individual QPs, there could be
policy flexibility in associating more than one QoS level with a given
HCA/port combo.

Alfred Hartmann, Ph.D. <mailto:[email-masked]> 
Vieo, Inc. <http://www.vieo.com/> 
12416 Hymeadow Drive, Suite 200
Austin, TX 78750
+1.512.257.3031, x267

>  -----Original Message-----
>  From: Jerry Chu [mailto:[email-masked]]
>  Sent: Tuesday, March 19, 2002 3:15 AM
>  To: Culley, Paul
>  Cc: H.K. Jerry Chu; [email-masked]; [email-masked]
>  Subject: Re: [Ipoverib] BOOTP/DHCP chaddr field
>  
>  
>  Paul,
>  
>  My comments are embeded below
>  
>  >...
>  ><snip>
>  >
>  >>I am more open to using LID + QPN rather than GID + SIDR.
>  >>
>  >>For example a simple issue with SIDR and DHCP:
>  >>
>  >>       As noted by Akihiko, and I agree, there may be 
>  multiple IPoIB
>  >>       interfaces over the same port but these interfaces 
>  would have
>  >>       different QPNs. Greater than one IPoIB interface 
>  per port and
>  >>       the server or the client side CM have no way to 
>  determine the
>  >>       QPN to send back; server doesn't have a good distinguishing
>  >>       value to give to the client CM.
>  >>
>  >
>  ><endprc>
>  I was alluding to multiple QPs in the same IB partition. For 
>  multiple 
>  P_Keys, each P_Key/
>  IB partitions defines a unique IP link, which is usually served by a 
>  different DHCP server.
>  Different interfaces on different IP links can possess the 
>  same hardware 
>  address. This is
>  similar to IP/Ethernet.
>  
>  >
>  >
>  > If one
>  >wants multiple interfaces out of the same node to the same IP link,
>  >
>  Note again I was talking about "the same IP link", i.e. the 
>  same P_Key. 
>  I don't see the value
>  of providing multiple "virtual" interfaces on the same IB 
>  partition by 
>  using the same HCA,
>  same port, but only different QPs.
>  
>  >
>  >one add multiple HCAs/ports. Different QPs attched to the same HCA
>  >port has the same hardware failure domain so I don't see what value
>  >it buys. If this is for load-balancing purpose one will 
>  probably have
>  >to resort to SIDR like you have suggested anyway. Using GID 
>  leaves no
>  >room for any additional flag in the hardware address. But since SIDR
>  >must be consulted now, all the advanced functions can be 
>  moved there.
>  >
>  >The above is just some of my own preliminary thoughts. I hate to go
>  >down this route of debating hardware address format again unless we
>  >decide against the broadcast flag workaround.
>  ><prc> The broadcast work around seems quite adequate to me <endprc>
>  >
>  If the WG comes to a consensus on this then the above 
>  discussion about 
>  QPs is moot.
>  
>  Rgds,
>  
>  Jerry
>  
>  >
>  >
>  >I'm glad this DHCP issue is brought up now, not later (thanks Roy!).
>  >I wonder how many other issues are lurking out there. I encourage
>  >everyone to go through the current draft proposals very carefully
>  >(speaking as a co-chair now :-) so we don't have to go through the
>  >pain of respin the design later.
>  >
>  >Jerry
>  >
>  >>Vivek
>  >>
>  >
>  >