On 10/11/2016 2:10 PM, Paolo Abeni wrote: > On Tue, 2016-10-11 at 12:01 -0600, Jason Gunthorpe wrote: >>> AFAICS the max mtu is already underlying h/w dependent, how does such >>> differences are currently coped by ? (I'm sorry I lack some/a lot of IB >>> back-ground) >> >> It isn't h/w dependent. In CM mode the MTU is 65520 because that is >> what is hard coded into the ipoib driver. We tell everyone to use that >> number. Eg see RH's docs on the subject: >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Configuring_IPoIB.html >> >> AFAIK, today everyone just wires that number into their scripts, so we >> have to mass change everything to the smaller number. Well, not exactly. Even if we put 65520 into the scripts, the kernel will silently drop it down to 65504. It actually won't require anyone change anything, they just won't get the full value. I experimented with this in the past for other reasons and an overly large MTU setting just resulted in the max MTU. I don't know if that's changed, but if it still works that way, this is much less of an issue than it might otherwise be. >> That sounds >> really hard, IMHO if there is any way to avoid it we should, even if >> it is a little costly. > > Thank you for the details! > > The first s/g fragment (the head buffer) is not allocated with the page > allocator, so perhaps there is some not too difficult/costly way out of > this. > > > > > > -- Doug Ledford <dledford@xxxxxxxxxx> GPG Key ID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
