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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 11 Oct 2016 14:50:11 -0400
From:   Doug Ledford <dledford@...hat.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:     Paolo Abeni <pabeni@...hat.com>, 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:30 PM, Jason Gunthorpe wrote:
> On Tue, Oct 11, 2016 at 02:17:51PM -0400, Doug Ledford wrote:
> 
>> 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.
> 
> So it is just docs and relying on PMTU? That is not as bad..
> 
> Still would be nice to avoid if at all possible..

I agree, but we have a test getting ready to commence.  We'll know
shortly how much the reduced MTU effects things because they aren't
going to alter any of their setup, just put the new kernel in place, and
see what happens.


-- 
Doug Ledford <dledford@...hat.com>
    GPG Key ID: 0E572FDD



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