>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.
This is what I meant by the MTU is implied by the other fields. I was thinking about it this way. If a PR query contains the SLID, DLID, SL, I would expect the SA to lookup the MTU for this path and return it. Is there any advantage or reason to include the MTU in such a query? Taking this across subnets, if a PR query contains the SGID, DGID, TC, and FL, does this change whether the MTU should be specified? I'm not trying to argue against including the MTU, but I don't know if IPoIB or the SA should specify it. (And I'm neither an IPoIB nor SA expert.) >The MTU of every unicast path used must be greater than the Linux >interface MTU so that the stack produces correctly sized fragments. As you mentioned, this doesn't holds for IPoIB-CM. The MTU of the path is less than the MTU sent by the stack, and the path MTUs could differ, including being less than the broadcast MTU. (I don't know that the implementation supports different path MTUs, but it could in theory.) >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. Couldn't IPoIB fragment the packets if it needed? (Not sure what that would do to the performance.) How does IPoIB-CM handle the case where the device MTU is, say, 64k, but the remote side only supports UD? - Sean _______________________________________________ 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
