Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752870AbbDARzg (ORCPT ); Wed, 1 Apr 2015 13:55:36 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:59344 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751210AbbDARzf convert rfc822-to-8bit (ORCPT ); Wed, 1 Apr 2015 13:55:35 -0400 Date: Wed, 01 Apr 2015 13:55:32 -0400 (EDT) Message-Id: <20150401.135532.1368728758929086692.davem@davemloft.net> To: klamm@yandex-team.ru Cc: hannes@stressinduktion.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] net: sysctl for RA default route MTU From: David Miller In-Reply-To: <68621427882330@webcorp01g.yandex-team.ru> References: <1427834148.979686.247747037.29964C1B@webmail.messagingengine.com> <20150331.164923.229749666073516444.davem@davemloft.net> <68621427882330@webcorp01g.yandex-team.ru> X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 01 Apr 2015 10:55:34 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1423 Lines: 33 From: Roman Gushchin Date: Wed, 01 Apr 2015 12:58:50 +0300 > 31.03.2015, 23:49, "David Miller" : >> From: Hannes Frederic Sowa >> Date: Tue, 31 Mar 2015 22:35:48 +0200 >>> ?Could you quickly comment on what you had in mind? I guess it is about >>> ?handling RA in user space on the end hosts and overwriting MTU during >>> ?insertion of the routes? >> >> Even after reading your email I have no idea why you can't just have >> RA provide a 1500 byte MTU, everything else uses the device's 9000 >> MTU, problem solved? > > Because the MTU (provided by RA) is assigned to the device. Ok, that severely limits the usefulness of this option I guess. The next question I have is about the behavior of the new setting in the presence of an RA MTU option. It seems like the sysctl doesn't override that RA MTU option, but rather just clamps it. And then if it's in range, this controls only whether the default route has it's MTU adjusted. That doesn't make any sense to me if we then go and do the rt6_mtu_change() call unconditionally. The route metric update and the rt6_mtu_change() go hand in hand. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/