On Tue, 2015-06-09 at 09:06 +0300, Erez Shitrit wrote:
> On Tue, Jun 9, 2015 at 12:04 AM, Doug Ledford <[email protected]> wrote:
> > On Mon, 2015-06-08 at 10:42 -0600, Jason Gunthorpe wrote:
> >> On Sun, Jun 07, 2015 at 01:36:11PM +0300, Erez Shitrit wrote:
> >> >
> >> > When switching between modes (datagram / connected) change the MTU
> >> > accordingly.
> >> > datagram mode up to 4K, connected mode up to (64K - 0x10).
> >>
> >> Is this a bug fix (describe the user visible impact)? Should it go to
> >> -stable? Add a Fixes: line?
> >
> > I'm not sure I would call it a bug.  Setting the MTU to max
> > automatically is a policy decision more than anything else.  Currently,
> > you have to enable connected mode, then set the MTU.  Both initscripts
> > and NetworkManager do this for you on Red Hat, so the user sees no
> > difference here.  I can't speak to other OSes.  I'm OK with setting
> 
> The only real reason for a user to switch to CM mode is for the
> performance he can get, and this is only by the huge MTU the CM gives,
> so it somehow should be part of the "mode setting".
> As you said RH does it (in the new versions of its OS's only)

No, we do it in all versions of our OS, but you have to set the MTU
parameter, we don't default it to anything for you (but this is no
different than setting CM).  This is normal device setup.  Just like we
don't default Ethernet interfaces to jumbo frames, the user needs to set
the MTU on that interface.  And the user gets benefit at MTUs less than
jumbo size.

>  via
> scripting outside of the driver code, other vendor doesn't.
> 
> > connected mode MTU to max by default once we get the scatter/gather
> > support for IPoIB added.
> 
> OK, great. Thanks.
> 
> > --
> > Doug Ledford <[email protected]>
> >               GPG KeyID: 0E572FDD
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to [email protected]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Doug Ledford <[email protected]>
              GPG KeyID: 0E572FDD

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to