Re: Please read - proposed WG termination
Vivek Kashyap <[email protected]> Thu, 1 Sep 2005 14:42:27 -0700 (PDT)
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 1 Sep 2005, Michael Krause wrote: > At 10:51 AM 9/1/2005, Vivek Kashyap wrote: >> On Thu, 1 Sep 2005, Roland Dreier wrote: >> >>> Bernard> In the HPC world most clusters use the cluster fabric ( >>> Bernard> and IB is the future direction ) for both MPI and IP >>> Bernard> traffic. The IP traffic is usually for parallel file >>> Bernard> systems and system management and control. This high >>> Bernard> bandwidth IP network is required in most production HPC >>> Bernard> clusters. With the current IPoIB only using UD, the >>> Bernard> performance is dismal. Our simulations using the small >>> Bernard> packet MTU of IB says that the parallel file systems ( >>> Bernard> GPFS, PVFS, Lustre etc ) can only get 25% of a 4X IB link >>> Bernard> today and at 12X it will be about 10%. >>> >>> It's not clear to me that IPoIB-CM is really the answer here. First >>> of all, for Linux to take advantage of a 64K MTU, major surgery to the >>> network stack will be required. Production systems have trouble even >>> enabling 8K jumbo frames, because the kernel can't allocate two >>> physically contiguous buffers to use for receive. Given that no >> >> That is an implementation issue in Linux and shouldn't effect the protocol. > > Linux does support large send off-load today so it is not clear what the > issue is you are speaking of above. Let us say that even if there is an issue with 8K frames/contiguous memory allocation in Linux, it is a Linux specific issue. > > >>> current IB hardware can offload TCP/IP checksums for multi-packet RC >>> messages, it's not clear how feasible this network stack surgery is. >> >> Checksum offload is not part of the specification but an HCA feature. > > It is also not that hard to implement. agreed and is not relevant to developing the protocol. > > > >>> Second, if the justification for IPoIB-CM is really for parallel file >> >> The justification is better performance through larger MTU, and leveraging >> connectd modes's apm capability. I'd view parallel fs is just one >> application that can use it. > > Just to clarify, there is no change in physical MTU. The IB hardware is > unchanged w.r.t. the MTU. All that is done is the same concept as for large > send off-load - tell the network stack there is a larger MTU and let the > hardware SAR the segment / datagram into physical units of transfer. yes, it is for a higher IP MTU and brings large sendoff benefits to IPoIB. Vivek > > Mike > > >> Vivek >> >>> systems, then it seems much more promising to run the file system >>> natively on InfiniBand. For example, since Lustre is implemented on >>> top of the Portals abstraction, native implementations of Lustre have >>> been in use on IB, Myrinet, Quadrics, etc. for quite some time. >>> >>> - R. >>> >> >> _______________________________________________ >> IPoverIB mailing list >> [email protected] >> https://www1.ietf.org/mailman/listinfo/ipoverib >