From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3430C43331 for ; Thu, 26 Mar 2020 18:49:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C87C42074D for ; Thu, 26 Mar 2020 18:49:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585248579; bh=fQSeaG7HJEhFR28TdvJvvUxw8rg/7HSJEcZM+/90BtA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=Kn8GoYfA/aC2Lp45qve2TrJsrSHxS5ndy4AbuRgqzjcA+3nJ031W7BoXPdVHpSgaN 0kZ4W1wnBy5L9th5iS6dVlocq+Ye3CTahTtqXZ2JXlll1BKSaw5umtCkTvcfIOgK2q HJPuRLhJk9tIMt82E3DSKs4sfEOeliFihfgre7C8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727026AbgCZStj (ORCPT ); Thu, 26 Mar 2020 14:49:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:44688 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725994AbgCZSti (ORCPT ); Thu, 26 Mar 2020 14:49:38 -0400 Received: from kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com (unknown [163.114.132.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 97C7520714; Thu, 26 Mar 2020 18:49:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585248578; bh=fQSeaG7HJEhFR28TdvJvvUxw8rg/7HSJEcZM+/90BtA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HTGIeHxj+ZaPCId/iRC7ZiHRb+5CKhR2cPJ33TnPVlOSynA00Z7VJZ8xOVS+e9BCU UXqt1IbkpZEpug1D/RNO378HZ4VBmk051EeYNrg0jCeQqFdeUPyfgKtTuPzCA/cfqk PDDDEk1aq1sLEqt3ptttInmxnyEJoxn5akggKkfI= Date: Thu, 26 Mar 2020 11:49:35 -0700 From: Jakub Kicinski To: Nikolay Aleksandrov Cc: Vladimir Oltean , Ido Schimmel , Andrew Lunn , Florian Fainelli , Vivien Didelot , "David S. Miller" , Jakub Kicinski , murali.policharla@broadcom.com, Stephen Hemminger , Jiri Pirko , netdev Subject: Re: [PATCH v2 net-next 10/10] net: bridge: implement auto-normalization of MTU for hardware datapath Message-ID: <20200326114935.22885985@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20200325152209.3428-1-olteanv@gmail.com> <20200325152209.3428-11-olteanv@gmail.com> <20200326101752.GA1362955@splinter> <20200326113542.GA1383155@splinter> <83375385-7881-53b7-c685-e166c8bdeba4@cumulusnetworks.com> <25bc3bf2-0dea-5667-8aae-c57a2a693bec@cumulusnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 26 Mar 2020 14:38:57 +0200 Nikolay Aleksandrov wrote: > On 26/03/2020 14:25, Vladimir Oltean wrote: > > On Thu, 26 Mar 2020 at 14:19, Nikolay Aleksandrov > > wrote: > >> > >> On 26/03/2020 14:18, Vladimir Oltean wrote: > >>> On Thu, 26 Mar 2020 at 14:06, Nikolay Aleksandrov > >>> wrote: > >>>> > >>>> On 26/03/2020 13:35, Ido Schimmel wrote: > >>>>> On Thu, Mar 26, 2020 at 12:25:20PM +0200, Vladimir Oltean wrote: > >>>>>> Hi Ido, > >>>>>> > >>>>>> On Thu, 26 Mar 2020 at 12:17, Ido Schimmel wrote: > >>>>>>> > >>> [snip] > >>>>> > >>>>> I think you should be more explicit about it. Did you consider listening > >>>>> to 'NETDEV_PRECHANGEMTU' notifications in relevant drivers and vetoing > >>>>> unsupported configurations with an appropriate extack message? If you > >>>>> can't veto (in order not to break user space), you can still emit an > >>>>> extack message. > >>>>> > >>>> > >>>> +1, this sounds more appropriate IMO > >>>> > >>> > >>> And what does vetoing gain me exactly? The practical inability to > >>> change the MTU of any interface that is already bridged and applies > >>> length check on RX? > >>> > >> > >> I was referring to moving the logic to NETDEV_PRECHANGEMTU, the rest is up to you. > >> > > > > If I'm not going to veto, then I don't see a lot of sense in listening > > on this particular notifier either. I can do the normalization just > > fine on NETDEV_CHANGEMTU. > > I should've been more explicit - I meant I agree that this change doesn't belong in > the bridge, and handling it in a notifier in the driver seems like a better place. > Yes - if it's not going to be a vetto, then CHANGEMTU is fine. I'm not sure pushing behavior decisions like that out to the drivers is ever a good idea. Linux should abstract HW differences after all, we don't want different drivers to perform different magic behind user's back. I'd think if HW is unable to apply given configuration vetoing is both correct and expected..