From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754600AbcJUIor (ORCPT ); Fri, 21 Oct 2016 04:44:47 -0400 Received: from vps0.lunn.ch ([178.209.37.122]:50462 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754363AbcJUIoo (ORCPT ); Fri, 21 Oct 2016 04:44:44 -0400 Date: Fri, 21 Oct 2016 10:44:41 +0200 From: Andrew Lunn To: Florian Fainelli Cc: Jarod Wilson , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Asbjoern Sloth Toennesen , R Parameswaran , Vivien Didelot Subject: Re: [PATCH net] net: remove MTU limits on a few ether_setup callers Message-ID: <20161021084441.GC16974@lunn.ch> References: <20161021032527.12954-1-jarod@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 On Thu, Oct 20, 2016 at 08:42:46PM -0700, Florian Fainelli wrote: > Le 20/10/2016 à 20:25, Jarod Wilson a écrit : > > These few drivers call ether_setup(), but have no ndo_change_mtu, and thus > > were overlooked for changes to MTU range checking behavior. They > > previously had no range checks, so for feature-parity, set their min_mtu > > to 0 and max_mtu to ETH_MAX_MTU (65535), instead of the 68 and 1500 > > inherited from the ether_setup() changes. Fine-tuning can come after we get > > back to full feature-parity here. > > > > CC: netdev@vger.kernel.org > > Reported-by: Asbjoern Sloth Toennesen > > CC: Asbjoern Sloth Toennesen > > CC: R Parameswaran > > Signed-off-by: Jarod Wilson > > --- > > > diff --git a/net/dsa/slave.c b/net/dsa/slave.c > > index 68714a5..d0c7bce 100644 > > --- a/net/dsa/slave.c > > +++ b/net/dsa/slave.c > > @@ -1247,6 +1247,8 @@ int dsa_slave_create(struct dsa_switch *ds, struct device *parent, > > slave_dev->priv_flags |= IFF_NO_QUEUE; > > slave_dev->netdev_ops = &dsa_slave_netdev_ops; > > slave_dev->switchdev_ops = &dsa_slave_switchdev_ops; > > + slave_dev->min_mtu = 0; > > + slave_dev->max_mtu = ETH_MAX_MTU; > > SET_NETDEV_DEVTYPE(slave_dev, &dsa_type); > > Actually for DSA, a reasonable minimum is probably 68 for the following > reasons: ETH_ZLEN of 60 bytes + FCS (4 bytes) + 2/4/8 bytes of > Ethernet switch tag (which is dependent on the tagging protocol > used). Humm, isn't the switch tag added by the layer below this? So this should be - 2/4/8 bytes, so that the assembled frame that actually hits the conduit interface has an MTU of 64. > Such an Ethernet interface would submit packets through the conduit > interface which is connected to an Ethernet switches, and those > typically discard packets smaller than 64 bytes +/- their custom tag > length. I have a purely theoretical observation, i.e. i have not checked the datasheets. You can also control some of the Marvell switches by sending it ethernet frames containing commands. Most commands are 4 bytes long. So an Ethernet header + 4 bytes is < 64. I expect the switch will accept command frames which are padded to stop them being runts. Also, such frames will be submitted to the conduit interface, not the slave interface. Andrew