Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752837AbdHRPEH (ORCPT ); Fri, 18 Aug 2017 11:04:07 -0400 Received: from vps0.lunn.ch ([178.209.37.122]:34949 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752725AbdHRPEE (ORCPT ); Fri, 18 Aug 2017 11:04:04 -0400 Date: Fri, 18 Aug 2017 17:03:58 +0200 From: Andrew Lunn To: Salil Mehta Cc: "davem@davemloft.net" , "Zhuangyuzeng (Yisen)" , "lipeng (Y)" , "dan.carpenter@oracle.com" , "mehta.salil.lnk@gmail.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , Linuxarm Subject: Re: [PATCH net-next] net: hns3: Add support to change MTU in hardware & netdev Message-ID: <20170818150358.GA3258@lunn.ch> References: <20170818113558.71928-1-salil.mehta@huawei.com> <20170818133128.GA523@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1510 Lines: 37 > > > + /* MTU range: 68 - 9706 */ > > > + netdev->min_mtu = ETH_MIN_MTU; > > > > http://elixir.free- > > electrons.com/linux/latest/source/net/ethernet/eth.c#L361 > Supported range of Min and Max MTU should be at the discretion > of the driver. Therefore, initialization looks fine to me. > > I could not clearly understand the problem being highlighted > over here. Could you further clarify? This is already setting min_mtu to ETH_MIN_MTU. There is no need for you to set it. > > > #define HNS3_RING_MAX_PENDING 32768 > > > +#define HNS3_MAX_MTU 9728 > > > > It seems odd that it does not already exists somewhere. The core does > > not enforce the MTU. You could be passed a frame which is bigger. So > > you should check before trying to pass something to the hardware which > > the hardware cannot handle. > There is a check already in place for this as well since 4.10-rc1. Yes, the core will check when changing the MTU. But when passing frames to be transmitted, it does not check the frame fits the MTU. DSA actually makes use of this, when passing frames to an Ethernet switch attached to the interface. We need to add an extra header to the frame, which makes the frame bigger than the MTU. Most Ethernet drivers are happy with this, they send the frame. Other reject it, and we have had to make driver changes. And some just explode :-( If 9728 is a hard limit for your device, you should check when passed a frame to make sure it is actually <= 9728 bytes in length. Andrew