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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 B708BC64E90 for ; Mon, 30 Nov 2020 23:44:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 74AAD207BB for ; Mon, 30 Nov 2020 23:44:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730186AbgK3Xn7 (ORCPT ); Mon, 30 Nov 2020 18:43:59 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:58712 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729627AbgK3Xn7 (ORCPT ); Mon, 30 Nov 2020 18:43:59 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kjsKA-009b6p-6D; Tue, 01 Dec 2020 00:11:14 +0100 Date: Tue, 1 Dec 2020 00:11:14 +0100 From: Andrew Lunn To: Vladimir Oltean Cc: Rasmus Villemoes , Network Development , Florian Fainelli Subject: Re: warnings from MTU setting on switch ports Message-ID: <20201130231114.GI2073444@lunn.ch> References: <20201130160439.a7kxzaptt5m3jfyn@skbuf> <61a2e853-9d81-8c1a-80f0-200f5d8dc650@prevas.dk> <20201130223507.rav22imba73dtfxb@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201130223507.rav22imba73dtfxb@skbuf> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > A thought: Shouldn't the initialization of slave_dev->max_mtu in > > dsa_slave_create() be capped by master->max_mtu minus tag overhead? > > Talk to Andrew: > https://www.spinics.net/lists/netdev/msg645810.html Yes, this is historic. DSA started life with Marvell switches connected to Marvell MACs. And Marvell MACs always allowed frames bigger than the MTU to be sent/received. A few more MACs were paired with Marvell switches, and they also happened to allow bigger frames than the MTU to be used. So it all worked fine until a MAC/Switch pair came along where the MAC did not pass frames bigger than the MTU. We could not break backwards compatibility, so decided to ask the MAC to up its MTU, but not error out if it failed. It was like that for a long time, until Vladimir added jumbo support. Then you do need to know if the MAC supports bigger MTU, so you can disallow jumbo. So this warning got added. Andrew