Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755781AbcJVSw3 (ORCPT ); Sat, 22 Oct 2016 14:52:29 -0400 Received: from einhorn.in-berlin.de ([192.109.42.8]:50017 "EHLO einhorn.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753168AbcJVSw1 (ORCPT ); Sat, 22 Oct 2016 14:52:27 -0400 X-Envelope-From: stefanr@s5r6.in-berlin.de Date: Sat, 22 Oct 2016 20:51:57 +0200 From: Stefan Richter To: Jarod Wilson Cc: Sabrina Dubroca , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Faisal Latif , linux-rdma@vger.kernel.org, Cliff Whickman , Robin Holt , Jes Sorensen , Marek Lindner , Simon Wunderlich , Antonio Quartulli Subject: Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers Message-ID: <20161022205157.0b89a013@kant> In-Reply-To: <20161022113607.55832988@kant> References: <20161019023333.15760-1-jarod@redhat.com> <20161019023333.15760-7-jarod@redhat.com> <20161019160546.GC11224@bistromath.localdomain> <20161020003846.64f85f7e@kant> <20161020031641.GJ18569@redhat.com> <20161022113607.55832988@kant> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1291 Lines: 32 On Oct 22 Stefan Richter wrote: > On Oct 19 Jarod Wilson wrote: > > On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote: > > > On Oct 19 Sabrina Dubroca wrote: > > > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote: [...] > > > > > @@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit, > > > > > max_mtu = (1 << (card->max_receive + 1)) > > > > > - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE; > > > > > net->mtu = min(1500U, max_mtu); > > > > > + net->min_mtu = ETH_MIN_MTU; > > > > > + net->max_mtu = net->mtu; > > > > > > > > But that will now prevent increasing the MTU above the initial value? > > > > > > Indeed, therefore NAK. > > > > However, there's an explicit calculation for 'max_mtu' right there that I > > glazed right over. It would seem perhaps *that* should be used for > > net->max_mtu here, no? > > No. This 'max_mtu' here is not the absolute maximum. It is only an > initial MTU which has the property that link fragmentation is not > going to happen (if all other peers will at least as capable as this > node). Besides, card->max_receive is about what the card can receive (at the IEEE 1394 link layer), not about what the card can send. -- Stefan Richter -======----- =-=- =-==- http://arcgraph.de/sr/