On Tue, Aug 07, 2007 at 12:01:23PM -0700, Sean Hefty wrote: > >MTU - at a minimum the PR must request a MTU >= than the interface > >MTU, having a MTU that is exactly equal to the broadcast group MTU > >seems fine to me. The SM should be able to do >= internally. > > My thoughts on MTU (and rate) are that since it isn't carried in any of the > headers, we should be able to derive the maximum MTU from the other fields. > Plus, we've had situations in the past where a smaller MTU than the maximum > performed better than the max, so I'm hesitant to add MTU to the query.
Well, the MTU isn't explicity carried in the headers, but if you send a 2K packet into a path that only supports 1K MTU then it will be discarded. In that sense the MTU is included in the headers. The MTU of every unicast path used must be greater than the Linux interface MTU so that the stack produces correctly sized fragments. If you want to use the 1k is fast feature of a tavor then I was under the impression that was done under a reduced IP interface MTU? Linux has no per-arp entry MTU so I don't know how you'd integrate the idea of different L2 destinations having different MTUs with the current stack. The only case I could see not including the MTU would be if RC is used as the transport, then the IB level MTU does not matter. Jason _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
