Re: [PATCH rdma-next V1 1/9] IB/ipoib: Add warning message when changing the MTU in UD over the max range

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2634 bytes --]

On Fri, Jan 13, 2017 at 05:15:07PM +0200, Leon Romanovsky wrote:
> On Thu, Jan 12, 2017 at 04:58:28PM -0500, Doug Ledford wrote:
> > On Thu, 2017-01-12 at 21:35 +0200, Leon Romanovsky wrote:
> > > 
> > > First of all, thank you for fixing wording, for me it is the hardest
> > > part of every commit.
> >
> > No worries.
> >
> > > Second, I have a different view from you on the issue. User
> > > configured
> > > some value, which is not correct for IPoIB. In ideal world (without
> > > legacy),
> > > we were supposed to return error to him with proper message,
> >
> > If you set an impossible MTU on an ethernet adapter, you get a return
> > of EINVAL.  But it doesn't mess with the kernel log at all, it's *just*
> > EINVAL to the calling program.
> >
> > >  but in our
> > > case (legacy applications) we can't (we tried and it broke some
> > > legacy
> > > ifcongfig, if I remember well).
> >
> > ifconfig is what I used to test what Ethernet does, so it should be
> > well and truly used to EINVAL as a return.
>
> I'll recheck with Feras next week which legacy tool
> didn't work and will post it.

At the end, it was ethtool and according to Jason's comments it was
correct thing do not to put return value, so we are fine.

>
> >
> > >  So it leaves us with one available
> > > option is to warn user about improper value.
> >
> > Even if you want to alert the user, there is no need to warn.  Warn is
> > reserved for something that is a serious error or condition, this is an
> > EINVAL of something that is, at best, a performance issue.  Unless path
> > MTU support is broken, failing to set a larger MTU will not ever hinder
> > actual operation.  So we should never be dumping out KERN_WARN messages
> > into the kernel log that will ping up on any root login session as well
> > as clutter the kernel dmesg output.
> >
> > > User should know that he supplied wrong parameter.
> >
> > User can still find out, they just won't get proactive pings on all
> > root sessions, instead they will have to look in the dmesg output
> > because they are trying to figure out why their command didn't work.
> >
> > > >
> > > >
> > > > --
> > > > Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > >     GPG KeyID: B826A3330E572FDD
> > > >    
> > > > Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57
> > > > 2FDD
> > >
> > >
> > --
> > Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >     GPG KeyID: B826A3330E572FDD
> >    
> > Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>
>



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]