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@xxxxxxxxxx> > > > > GPG KeyID: B826A3330E572FDD > > > > > > > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 > > > > 2FDD > > > > > > > > -- > > Doug Ledford <dledford@xxxxxxxxxx> > > GPG KeyID: B826A3330E572FDD > > > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD > >
Attachment:
signature.asc
Description: PGP signature
