From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_MED,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08EC8C282DE for ; Wed, 5 Jun 2019 04:58:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CB4BC2083E for ; Wed, 5 Jun 2019 04:58:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Ce6uT+rS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726341AbfFEE6d (ORCPT ); Wed, 5 Jun 2019 00:58:33 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:33162 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725268AbfFEE6d (ORCPT ); Wed, 5 Jun 2019 00:58:33 -0400 Received: by mail-wm1-f65.google.com with SMTP id v19so864835wmh.0 for ; Tue, 04 Jun 2019 21:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tvZ0sXc7T+PfuYrXldyLNvmzWS0RxOt+TFpjmhqi7iY=; b=Ce6uT+rSj9byp1iphLj+PvFUcXE4c9IZ7n90+TpSWkTGiqj3QikS46XQC9HwI30Rqh F2h91arNPZRohyYSAqfvwPHzcF0d5vND/ceOpMxI8Lfyan8vc9iTeofYdKHfhI9PfXxD rpWfXOJvYsQT+0SyWsgOa8Py3dgrhURPw2WVPNlJkawAilI04eR2Fc2XzixPezt979TR xERAFSwPiI/VY4phslX8F98I6yHsc4LW/vUhT5Nyx28dHSRyCEk38q/xz/YWkDEjCuwO qSw6dptsShDauZN97+Pk+vtmaAMYb4Gm9b852omnpSRqOuTqjcMVr/81TrsAWZ2gpXYf Iqow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tvZ0sXc7T+PfuYrXldyLNvmzWS0RxOt+TFpjmhqi7iY=; b=jihxVrhF3X9Jq5Ze+PcglizlaxtSxk5HgpQ9nfeJn2jD0NmKQjqbgVhw5Bn5AwbMo6 BIVTAJhDuPxWFRHK1hZi2V64dT7R7k8hTIoX12fwKkWL5gSiabKqglLUaiGb/SkGkTh6 VULb5+87uTSYYKtVW4hm7UfrBrnwekpejhAxCS9CxKmalAc3fV91MpZcxU0wevODq+Io ByFsPfjNxco8p6hKSjWpCcLp45x04iJ2us+gO1LIojXiV7UWCe77CTsJerr7eMvRjs5i kI6OAxAmTRqzj+d1kP0aJk8Xue2k7wDKRaO6fDenJwJdN4jvSCf3z+/clq1pVJtk2gh4 MFHA== X-Gm-Message-State: APjAAAXy3VgtDo0+3X5j/cCDGnxgrQw81Uz0vpiE8EynWspZoA2Hxx4F OaBGyMNrs0bk+KVXzmsldPek7jHhVZhKJ0ul9fwDAQ== X-Google-Smtp-Source: APXvYqw9RLrse0P7VjccV/LhirPa6MoDx3BCgDbjB0A9EMgsAq5O+rPAKND21GC8a5C7yEX4Wfsxb7BCrAB/0lcPSL8= X-Received: by 2002:a05:600c:23d2:: with SMTP id p18mr10838383wmb.108.1559710710540; Tue, 04 Jun 2019 21:58:30 -0700 (PDT) MIME-Version: 1.0 References: <20190507091118.24324-1-liuhangbin@gmail.com> <20190508.093541.1274244477886053907.davem@davemloft.net> <20190605014344.GY18865@dhcp-12-139.nay.redhat.com> In-Reply-To: From: Lorenzo Colitti Date: Wed, 5 Jun 2019 13:58:18 +0900 Message-ID: Subject: Re: [PATCH net] fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied To: David Ahern Cc: Hangbin Liu , David Ahern , David Miller , Yaro Slav , Thomas Haller , Alistair Strachan , Greg KH , Linux NetDev , Mateusz Bajorski , =?UTF-8?Q?Maciej_=C5=BBenczykowski?= Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jun 5, 2019 at 12:58 PM David Ahern wrote: > I think it is crazy to add multiple identical rules given the linear > effect on performance. Not sure if this is what you were implying or not, but our code doesn't maintain multiple identical rules in steady state. It only uses them for make-before-break when something changes. > But, since it breaks Android, it has to be reverted. Well... the immediate problem on Android is that we cannot live with this going to LTS, since it is going to break devices in the field. As for making this change in 5.3: we might be able to structure the code differently in a future Android release, assuming the same userspace code can work on kernels back to 4.4 (not sure it can, since the semantics changed in 4.8). But even if we can fix this in Android, this change is still breaking compatibility with existing other userspace code. Are there concrete performance optimizations that you'd like to make that can't be made unless you change the semantics here? Are those optimizations worth breaking the backwards compatibility guarantees for?