On Fri, Jan 13, 2017 at 05:08:24PM +0200, Leon Romanovsky wrote: > On Thu, Jan 12, 2017 at 01:16:22PM -0700, Jason Gunthorpe wrote: > > On Thu, Jan 12, 2017 at 09:35:08PM +0200, Leon Romanovsky wrote: > > > > > > > In datagram mode, the IB UD (Unreliable Datagram) transport is used > > > > > so the MTU of the interface is equal to the IB L2 MTU minus the > > > > > IPoIB encapsulation header. Any request to change the MTU value > > > > > above the maximum range will change the MTU to the max allowed, but > > > > > will not show any warning message. An ipoib_warn is issued in such > > > > > cases, letting the user know that even though the value is legal, > > > > > it can't be currently applied. > > > > How does RC mode work then? > > RC mode doesn't have limitation on MTU size and it allows messages > larger than IB link-layer MTU. This is about what happens if the multicast MTU < unicast MTU - which is *exactly* the same case on RC and UD. IPoIB cannot send a 64k multicast MTU on RC either. > Maybe, I went too far by calling it error, but IMHO absence of indication to > user of decreased MTU is not good either. I don't see why we should 'solve' this for UD and ignore the same problem in RC. IMHO, the correct fix is to figure out how to limit multicast - there is something called multicast path MTU discovery - so maybe we are doing something wrong and breaking that (are we erroring too large packets inside ipoib properly?), or it is not working in the kernel or it isn't supported by the kernel ... Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
