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=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, USER_AGENT_NEOMUTT 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 C9A7DC43381 for ; Sun, 24 Mar 2019 03:55:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 86AD12080F for ; Sun, 24 Mar 2019 03:55:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="E3Edvqwa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727880AbfCXDz4 (ORCPT ); Sat, 23 Mar 2019 23:55:56 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:38586 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727727AbfCXDz4 (ORCPT ); Sat, 23 Mar 2019 23:55:56 -0400 Received: by mail-pf1-f193.google.com with SMTP id 10so4092964pfo.5 for ; Sat, 23 Mar 2019 20:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xaeVYgr1yhj/zphUlo5Eh/O2HLhFSIKIw3qQuJBG6Fc=; b=E3Edvqwa5LoDkg4SbyhdhJCKVSgth6ZDHe9MVg4Sli4q/HsMpfBTQXyZ3jLGMj1/K/ QJFxYPvxDh/NhUU6PMTXdvYDdA/QJP7lZCjHTS5ietZzEl4nWFfJSrhiRf6iEf6JiDcY P3jbwkakbh8g2EkOhuaT4Nr2yUj2Zt2Er6HrVbwjum072DAy0ilwWn46XtOQKVRJuR/q XxywC4Fp29IXjiilIWLA4jZt+y5VVepW8e6842TCV63d4SbduagHmWAAJ+TwFHJcYjGd /RFpAVIxb6CAp6krQNZ9Xy4/Cn2WP6jE2oWeL3LXnLubV3ZRfHpSornjD/OH7V0fvu8k H5rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xaeVYgr1yhj/zphUlo5Eh/O2HLhFSIKIw3qQuJBG6Fc=; b=DuREK4pbqJ1o5hpNafqhcm/rBjhTLDtN5cVC3qOyG7FUX4ghBtTo1oajT12toHEwOO 7foHFqaccjubttr8/A2jJT1B8kEiSQjHDiQr2N4Px8uVx7ueDDeMqRcRoKe3iF7QgEEL rAikrRt3Oi6yClNs6+bCSNc8w0BXYYH/bRS01WKnsOr2rFyVvKTLhPb8ZrOenERjhQ6c Ll1giCbPEcZbkC827pJKM69yV0NwVkOWmC41/A5KIgMt5ZkrG0diLgFCkuiqoGqxwsGI 9LQaQs2lUIDA+0+iqaqlON/Ra+XfJSozdCzPedTp0sOaTlAZJvzowWiPUaPfbn2wZqAu km+A== X-Gm-Message-State: APjAAAW1PHcqGbHd44Fx7icH0BaMj6mj38Ywcto2+vVKdzlqpE3wRt1F 6JkrkzlwcpS/v65UUAJM8nk= X-Google-Smtp-Source: APXvYqx0AyXKkQueelTTjgx6htc+vRzgwgzvydDVUWdzhs1TiMSTp/is0meZT7mef4JJlhLuUfsaxg== X-Received: by 2002:a62:b61a:: with SMTP id j26mr17198560pff.151.1553399755311; Sat, 23 Mar 2019 20:55:55 -0700 (PDT) Received: from ast-mbp ([2620:10d:c090:180::e844]) by smtp.gmail.com with ESMTPSA id j12sm13913422pgg.79.2019.03.23.20.55.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Mar 2019 20:55:54 -0700 (PDT) Date: Sat, 23 Mar 2019 20:55:52 -0700 From: Alexei Starovoitov To: David Miller Cc: dsahern@kernel.org, netdev@vger.kernel.org, dsahern@gmail.com, edumazet@google.com Subject: Re: [PATCH net-next] ipv6: Move ipv6 stubs to a separate header file Message-ID: <20190324035550.b4qjyl5ccfvc3tzi@ast-mbp> References: <20190322130609.11655-1-dsahern@kernel.org> <20190323.214023.610983922857554034.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190323.214023.610983922857554034.davem@davemloft.net> User-Agent: NeoMutt/20180223 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sat, Mar 23, 2019 at 09:40:23PM -0400, David Miller wrote: > From: David Ahern > Date: Fri, 22 Mar 2019 06:06:09 -0700 > > > From: David Ahern > > > > The number of stubs is growing and has nothing to do with addrconf. > > Move the definition of the stubs to a separate header file and update > > users. In the move, drop the vxlan specific comment before ipv6_stub. > > > > Code move only; no functional change intended. > > > > Signed-off-by: David Ahern > > Eric, I fully support David's overall plan to make separate nexthop > objects as it will significantly empower the stack to do more sensible > things when links flap etc. let's agree to disagree. 'link flaps' were not mentioned in the cover letter for: "net: Improve route scalability via support for nexthop objects" The _only_ value of 86 patches is to align linux kernel routing with switch ASICs, because cumulus is trying to reuse iproute2 to manage them. It was broken model to begin with and it keeps complicating routing when linux is used as a host while not achieving the goal of iproute2 for switches. Can anyone use off the shelf linux to manage trident/tomahawk switches? Nope. brcm sdk is still necessary. nexthop objects are essential to configure enterprise switches. Clearly cumulus customers don't like iproute2 style because it's missing this feature, so David's proposal is to add that to the kernel. Even after kernel and iproute2 understand nexthop id the kernel is still not going to be competitive with switching os. The linux kernel is an OS to run on the host cpu and to run on a control plane cpu of a switch. That is all great, but the reasons to push routing into the kernel of control plane cpu were weak. It's not using these routes. Such architecture allowed temporary reuse of bgp daemons, but it fails to scale. No need to push route to the kernel when kernel won't use them. Hence an alternative proposal: - introduce hooks at netlink layer and steal back and forth messages from your favorite daemon without populating the kernel - same for iproute2 netlink interaction