Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759522AbcJQU3t (ORCPT ); Mon, 17 Oct 2016 16:29:49 -0400 Received: from mail-qt0-f171.google.com ([209.85.216.171]:34074 "EHLO mail-qt0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759384AbcJQU3s (ORCPT ); Mon, 17 Oct 2016 16:29:48 -0400 Date: Mon, 17 Oct 2016 16:29:43 -0400 From: Jarod Wilson To: David Miller Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH net-next 00/15] ethernet: use core min/max MTU checking Message-ID: <20161017202943.GP14983@redhat.com> References: <20161017195417.48259-1-jarod@redhat.com> <20161017.160341.529517225075047124.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161017.160341.529517225075047124.davem@davemloft.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1452 Lines: 38 On Mon, Oct 17, 2016 at 04:03:41PM -0400, David Miller wrote: > From: Jarod Wilson > Date: Mon, 17 Oct 2016 15:54:02 -0400 > > > For the most part, every patch does the same essential thing: removes the > > MTU range checking from the drivers' ndo_change_mtu function, puts those > > ranges into the core net_device min_mtu and max_mtu fields, and where > > possible, removes ndo_change_mtu functions entirely. > > Jarod, please read my other posting. Done, didn't see it until just after I'd hit send, have replied there as well. > You've positively broken the maximum MTU for all of these drivers. > > That's not cool. > > And this series fixing things doesn't make things better, because now > we've significanyly broken bisection for anyone running into this > regression. Agreed, and my suggestion right now is to revert the 2nd patch from the prior series. I believe it can be resubmitted after all other callers of ether_setup() have been converted to have their own min/max_mtu. > You should have arranged this in such a way that the drivers needing > > 1500 byte MTU were not impacted at all by your changes, but that > isn't what happened. Yeah, I must admit to not looking closely enough at the state the first two patches left things in. It was absolutely my intention to not alter behaviour in any way, but I neglected to test sufficiently without this additional set applied. -- Jarod Wilson jarod@redhat.com