RE: ipoib-cm nits/clarifications
Dror Goldenberg <[email protected]> Thu, 20 Oct 2005 09:37:14 +0200
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0183684278== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D549.65CF5986" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5D549.65CF5986 Content-Type: text/plain > From: H.K. Jerry Chu [mailto:[email protected]] > Sent: Wednesday, October 19, 2005 6:57 PM > > >- page 10, section 6.0 - what is the final MTU of a > connection ? is it > >the minimum between > > the two "receive MTU" , or is it hybrid - different MTU per half > >connection ? > > Although there is really no reason to demand for a single MTU > value per connection as long as a sender never sends a > message large than the "Receive MTU" of the receiver, I'd > expect most implementations would want to choose one value > for both directions for simplicity. For that I'd suggest to > take the min as the final MTU for both directions so that the > side that advertises a 32KB MTU doesn't need to post 32KB > receive buffers and waste memory if the other side will never > send msgs larger than 16KB, for example. I agree. > > >I think that the current model for multiple connections > establishment > >between two peers works well for 1 connection but is broken for more > >than one connection. > >Because of cases where CM packets are dropped or travel on > different VLs, > >they > >might get reordered on the way and observed in a different > order than were > >originally > >sent. This breaks the current model which assumes that the > REQs are sent and > >processed in order. > > Isn't this a problem at the IB layer already, or this problem > is introduced by the 20byte comparison for the REQ crossing case? I think that it's a new problem because we're not letting the CM perform Active/Active on behalf of the ULP. However I think that the fundamental issue here is also that we're trying to use both Active/Active and Active/Passive semantics on the same "service" while expecting to end up with more than one simultaneous connection. Take a look at the pdf I've sent in the other mail, it tries to illustrate the problem. -Dror ------_=_NextPart_001_01C5D549.65CF5986 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45"> <TITLE>RE: [Ipoverib] ipoib-cm nits/clarifications</TITLE> </HEAD> <BODY> <BR> <BR> <P><FONT SIZE=2>> From: H.K. Jerry Chu [<A HREF="mailto:[email protected]">mailto:[email protected]</A>] </FONT> <BR><FONT SIZE=2>> Sent: Wednesday, October 19, 2005 6:57 PM</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> >- page 10, section 6.0 - what is the final MTU of a </FONT> <BR><FONT SIZE=2>> connection ? is it </FONT> <BR><FONT SIZE=2>> >the minimum between</FONT> <BR><FONT SIZE=2>> > the two "receive MTU" , or is it hybrid - different MTU per half </FONT> <BR><FONT SIZE=2>> >connection ?</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> Although there is really no reason to demand for a single MTU </FONT> <BR><FONT SIZE=2>> value per connection as long as a sender never sends a </FONT> <BR><FONT SIZE=2>> message large than the "Receive MTU" of the receiver, I'd </FONT> <BR><FONT SIZE=2>> expect most implementations would want to choose one value </FONT> <BR><FONT SIZE=2>> for both directions for simplicity. For that I'd suggest to </FONT> <BR><FONT SIZE=2>> take the min as the final MTU for both directions so that the </FONT> <BR><FONT SIZE=2>> side that advertises a 32KB MTU doesn't need to post 32KB </FONT> <BR><FONT SIZE=2>> receive buffers and waste memory if the other side will never </FONT> <BR><FONT SIZE=2>> send msgs larger than 16KB, for example.</FONT> </P> <BR> <P><FONT SIZE=2>I agree. </FONT> </P> <P><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> >I think that the current model for multiple connections </FONT> <BR><FONT SIZE=2>> establishment </FONT> <BR><FONT SIZE=2>> >between two peers works well for 1 connection but is broken for more </FONT> <BR><FONT SIZE=2>> >than one connection.</FONT> <BR><FONT SIZE=2>> >Because of cases where CM packets are dropped or travel on </FONT> <BR><FONT SIZE=2>> different VLs,</FONT> <BR><FONT SIZE=2>> >they </FONT> <BR><FONT SIZE=2>> >might get reordered on the way and observed in a different </FONT> <BR><FONT SIZE=2>> order than were</FONT> <BR><FONT SIZE=2>> >originally</FONT> <BR><FONT SIZE=2>> >sent. This breaks the current model which assumes that the </FONT> <BR><FONT SIZE=2>> REQs are sent and</FONT> <BR><FONT SIZE=2>> >processed in order.</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> Isn't this a problem at the IB layer already, or this problem </FONT> <BR><FONT SIZE=2>> is introduced by the 20byte comparison for the REQ crossing case?</FONT> </P> <P><FONT SIZE=2>I think that it's a new problem because we're not letting the CM </FONT> <BR><FONT SIZE=2>perform Active/Active on behalf of the ULP. However I think that the </FONT> <BR><FONT SIZE=2>fundamental issue here is also that we're trying to use both</FONT> <BR><FONT SIZE=2>Active/Active and Active/Passive semantics on the same "service" while </FONT> <BR><FONT SIZE=2>expecting to end up with more than one simultaneous connection.</FONT> <BR><FONT SIZE=2>Take a look at the pdf I've sent in the other mail, it tries to illustrate the </FONT> <BR><FONT SIZE=2>problem.</FONT> </P> <P><FONT SIZE=2>-Dror</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C5D549.65CF5986-- --===============0183684278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPoverIB mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipoverib --===============0183684278==--