[openib-general] Re: iWARP emulation protocol

[Kanevsky, Arkady]

> 
> An additional space preserving option that Arkady did not 
> mention is limiting the IP alias service to IPv4 addresses. 
> Anyone who really wants IPv6 addresses can get their SM to 
> assign IPv6 compatible GIDs. Of course the flat IPv6 option 
> is far simpler, and probably should be used unless a specific 
> application is identified where those extra 96 bits makes the 
> difference between making the private data be rewritten or left as is.
> 

This can be an extension to proposal 3 of last page.

Arkady Kanevsky                       email: arkady at netapp.com
Network Appliance                     phone: 781-768-5395
375 Totten Pond Rd.                  Fax: 781-895-1195
Waltham, MA 02451-2010          central phone: 781-768-5300
 


> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
> Sent: Tuesday, October 18, 2005 3:16 PM
> To: Roland Dreier; Kanevsky, Arkady
> Cc: swg at infinibandta.org; dat-discussions at yahoogroups.com; 
> openib-general at openib.org
> Subject: RE: [openib-general] Re: iWARP emulation protocol
> 
> 
>  
> 
> > -----Original Message-----
> > From: Roland Dreier
> > Sent: Tuesday, October 18, 2005 11:41 AM
> > To: Kanevsky, Arkady
> > Subject: [openib-general] Re: iWARP emulation protocol
> > 
> >     Arkady> uDAPL users.
> > 
> > 
> > 2) Are there real users or is this a generic uDAPL API thing?
> > 
> 
> uDAPL vs. kDAPL is irrelevant here. The user or Kernel 
> Consumer making the connection does not know whether their 
> peer is running in user or kernel, nor should they.
> 
> Every discussion of reducing the guaranteed private data size 
> in DAPL has produced adverse reactions from application 
> developers. They're either very good actors or were working 
> on actual applications.
> 
> An additional space preserving option that Arkady did not 
> mention is limiting the IP alias service to IPv4 addresses. 
> Anyone who really wants IPv6 addresses can get their SM to 
> assign IPv6 compatible GIDs. Of course the flat IPv6 option 
> is far simpler, and probably should be used unless a specific 
> application is identified where those extra 96 bits makes the 
> difference between making the private data be rewritten or left as is.
>