netdev - Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Oct 2016 14:17:51 -0400
From:   Doug Ledford <dledford@...hat.com>
To:     Paolo Abeni <pabeni@...hat.com>,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:     linux-rdma@...r.kernel.org, Sean Hefty <sean.hefty@...el.com>,
        Hal Rosenstock <hal.rosenstock@...il.com>,
        netdev@...r.kernel.org
Subject: Re: [PATCH] IB/ipoib: move back the IB LL address into the hard
 header

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@...hat.com>
    GPG Key ID: 0E572FDD



Download attachment "signature.asc" of type "application/pgp-signature" (885 bytes)