Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752261AbdHRPfQ convert rfc822-to-8bit (ORCPT ); Fri, 18 Aug 2017 11:35:16 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:33417 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751843AbdHRPfO (ORCPT ); Fri, 18 Aug 2017 11:35:14 -0400 From: Salil Mehta To: Andrew Lunn CC: "davem@davemloft.net" , "Zhuangyuzeng (Yisen)" , "lipeng (Y)" , "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 Thread-Topic: [PATCH net-next] net: hns3: Add support to change MTU in hardware & netdev Thread-Index: AQHTGBZFah6eHY/VdkiM5vNY65v5a6KJ+uMAgAAjiyD///ZNAIAAI2KA Date: Fri, 18 Aug 2017 15:34:59 +0000 Message-ID: References: <20170818113558.71928-1-salil.mehta@huawei.com> <20170818133128.GA523@lunn.ch> <20170818150358.GA3258@lunn.ch> In-Reply-To: <20170818150358.GA3258@lunn.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.181.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5997092F.024B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=169.254.1.205, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8f530bd678ba165def823cb47203b4f2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3076 Lines: 83 Hi Andrew > -----Original Message----- > From: Andrew Lunn [mailto:andrew@lunn.ch] > Sent: Friday, August 18, 2017 4:04 PM > 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 > > > > > + /* 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. I grep'ed entire code and could see min and max MTUs being set by the Respective Ethernet driver code. I also verified by the original patch floated by the Jarod where he did that Change across all the drivers https://patchwork.kernel.org/patch/9387361/ for example, file: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) netdev->priv_flags |= IFF_UNICAST_FLT; + /* MTU range: 81 - 9600 */ + netdev->min_mtu = 81; + netdev->max_mtu = MAX_MTU; Many such changes are present in the above mentioned patch. Hope I am not missing anything there? Thanks Salil > > > > > #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 :-( I see. IMHO HNS3 is currently limited by maximum buffer per descriptor which is 64k. I am sure such frames would get dropped in the hardware itself and which I guess should be more preferable than dropping in driver since it saves you some precious cpu cycles? So I am not able to appreciate the presence of such a MTU check in the live data-path. Maybe I am missing something here? Thanks Salil > > 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