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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 1573CC43381 for ; Fri, 1 Mar 2019 00:20:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D0FE0218AE for ; Fri, 1 Mar 2019 00:20:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Y0IcDnWU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732302AbfCAAUp (ORCPT ); Thu, 28 Feb 2019 19:20:45 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:33138 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732259AbfCAAUp (ORCPT ); Thu, 28 Feb 2019 19:20:45 -0500 Received: by mail-lf1-f67.google.com with SMTP id z23so4644754lfe.0 for ; Thu, 28 Feb 2019 16:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l/FQ+rET8OPP2gWjv8g+1Dm+Y2sUkV0rWkBjmwG0oGU=; b=Y0IcDnWUUgYE1nOBsZBuiz0VtkOox8U/rnf7548flDbR8zIMwG6eXHFlrxI+ErTywM 17C7mLnZEeoDr1CQFQ/l0RTwEHxbSc4eNDI1xpHqoL6DGBTXW3tOye+bQ54sZLdgDkGO BK+gtGNaqfiVjEGDMKV2FCgsQDlBdOYOJbUejx7HJJ5H6BULFklzN5z20uJqQ3s+QfAw v5D9f9ZLahsVAY9wnN5z4XUoKF57yfi0Gkk2nP1HwRm5jAREUrDgB0vb/Osw4MryOReo vhR89FMy/NpoHw+Uwk6/SO1N8dt5FpUlOQ4CcEdvDsAwc6MTouf4g8eHcniMfnvvSPJn j5tQ== 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=l/FQ+rET8OPP2gWjv8g+1Dm+Y2sUkV0rWkBjmwG0oGU=; b=j38OPCxVud+8W8V3zfXfa0gQuYrMipk0AU8gVGSYBlnB/elMHuuVuzk1xCgsR5Qh1G w8KC2bYBUBmro5oLihqboQrPoV3ZMG2R7woEoc9u8h2HwMRFOh0YCfh70V6eWkFipA// h4n40QDJNuZWCtQV9WhaL2MwfBTAJ3QQlAGw9/9QCqeTuyJI+N6YMYPfppGiabEt4lLW 3xYP4Uef3wkzl9HIKkqU9lTzs2k0kjkNzPM+zVnAcvxxnXFo25OCPjKsGxftg3287mMk Gl0k13cC1jEwyrGBxPxlYsIZMy7imVAHbSK3Nq/8h2ecrE6jhjwurobFjCd3hkLOMZar Q1ow== X-Gm-Message-State: APjAAAWiZBKDh/DXk8E2ruO1oCoAnY2e96gq/2TWRpFPclBkeKiWmpDc EdfMLa6wGwi89d4WOZDG25Ee6YxzrkTQzV6T4Ws= X-Google-Smtp-Source: APXvYqwWg1qGR4mf4emCtZVKswSe7msvAxSkPo7DnEj+PbYTm8oxLQwbOB66b1uhJoct1Mx+O2/dm1+GgwfGttH0t7o= X-Received: by 2002:ac2:5542:: with SMTP id l2mr1319189lfk.108.1551399642707; Thu, 28 Feb 2019 16:20:42 -0800 (PST) MIME-Version: 1.0 References: <20190227173710-mutt-send-email-mst@kernel.org> <20190227184601-mutt-send-email-mst@kernel.org> <20190227193923-mutt-send-email-mst@kernel.org> <20190227165205.307ed83c@cakuba.netronome.com> <20190227201857-mutt-send-email-mst@kernel.org> <20190227175218.736e13b6@cakuba.netronome.com> <20190227233812-mutt-send-email-mst@kernel.org> <20190228101356.39ac70aa@cakuba.netronome.com> <20190228143511-mutt-send-email-mst@kernel.org> <20190228115641.7afe6f09@cakuba.netronome.com> In-Reply-To: <20190228115641.7afe6f09@cakuba.netronome.com> From: Siwei Liu Date: Thu, 28 Feb 2019 16:20:28 -0800 Message-ID: Subject: Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework) To: Jakub Kicinski Cc: "Michael S. Tsirkin" , si-wei liu , "Samudrala, Sridhar" , Jiri Pirko , Stephen Hemminger , David Miller , Netdev , virtualization@lists.linux-foundation.org, "Brandeburg, Jesse" , Alexander Duyck , Jason Wang , liran.alon@oracle.com 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 Thu, Feb 28, 2019 at 11:56 AM Jakub Kicinski wrote: > > On Thu, 28 Feb 2019 14:36:56 -0500, Michael S. Tsirkin wrote: > > > It is a bit of a the chicken or the egg situation ;) But users can > > > just blacklist, too. Anyway, I think this is far better than module > > > parameters > > > > Sorry I'm a bit confused. What is better than what? > > I mean that blacklist net_failover or module param to disable > net_failover and handle in user space are better than trying to solve > the renaming at kernel level (either by adding module params that make > the kernel rename devices or letting user space change names of running > devices if they are slaves). Before I was aksed to revive this old mail thread, I knew the discussion could end up with something like this. Yes, theoretically there's a point - basically you don't believe kernel should take risk in fixing the issue, so you push back the hope to something in hypothesis that actually wasn't done and hard to get done in reality. It's not too different than saying "hey, what you're asking for is simply wrong, don't do it! Go back to modify userspace to create a bond or team instead!" FWIW I want to emphasize that the debate for what should be the right place to implement this failover facility: userspace versus kernel, had been around for almost a decade, and no real work ever happened in userspace to "standardize" this in the Linux world. The truth is that it's quite amount of complex work to get it implemented right at userspace in reality: what Michael mentions about making dracut auto-bonding aware is just tip of the iceberg. Basically one would need to modify all the existing network config tools to treat them well with this new auto-bonding concept: handle duplicate MACs, differentiate it with regular bond/team, fix boot time dependency of network boot and etc. Moreover, it's not a single distro's effort from cloud provider's perspective, at least not as simple as to say just move it to a daemon systemd/NM then work is done. We (Oracle) had done extensive work in the past year to help align various userspace components and work with distro vendors to patch shipped packages to make them work with the failover 3-netdev model. The work that needs to be done with userspace auto-bonding would be more involved than just that, with quite trivial value (just naming?) in turn that I suspect any developer in userspace could be motivated. So, simply put, no, we have zero interest in this direction. If upstream believes this is the final conclusion, I think we can stop discussing. Thanks, -Siwei > > > > for twiddling kernel-based interface naming policy.. :S > > > > I see your point. But my point is slave names don't really matter, only > > master name matters. So I am not sure there's any policy worth talking > > about here. > > Oh yes, I don't disagree with you, but others seems to want to rename > the auto-bonded lower devices. Which can be done trivially if it was > a daemon in user space instantiating the auto-bond. We are just > providing a basic version of auto-bonding in the kernel. If there are > extra requirements on policy, or naming - the whole thing is better > solved in user space.