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.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 8F80CC43381 for ; Thu, 28 Feb 2019 20:15:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 685FB218CD for ; Thu, 28 Feb 2019 20:15:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387548AbfB1UPA (ORCPT ); Thu, 28 Feb 2019 15:15:00 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:37099 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726088AbfB1UPA (ORCPT ); Thu, 28 Feb 2019 15:15:00 -0500 Received: by mail-qt1-f196.google.com with SMTP id a48so25119803qtb.4 for ; Thu, 28 Feb 2019 12:14:59 -0800 (PST) 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; bh=y3rqwncW3vo8MlMgpAbJwGsxRbtJ+kqCK4Nd2/G3TLU=; b=SS/sBom52L0mwVceHHhGncanopqpPUDKl7RZFqZ0p6zTsoNPJN6mw/tn//I4bENIL0 GT2yDykcD2KmLXL9krUvkUA9oHJ4j3LFv0j4nisQFk864rqZhLJhLDfkufhh7NgBPcq2 qSabLJskaWRadUFKXXyhWYksoNrVQI1XOSGTbgVgA0lVXrrHIWTtafST4XnT0IBj4O5+ +A1GBoFF+ad4UiHuYn705m+vpvrElM1reBIpMU62tfIWrx1zZJwrKug8XGAEDhk3ybka cyMycVNbi6oPmX3p7WaBt1LhzDnPrqOqZVp9/5cw60fDyDtxuN03slKvHrTzB7Nm4Dr6 ZOZQ== X-Gm-Message-State: APjAAAWhxYA2F6mtiQFYXWd7W1B0VtwPoSOpqBR5Z1jlYQkPH2l3Fipe XWV5xZy5cHNxaLaoVrj9/HfeDg== X-Google-Smtp-Source: APXvYqwYPghK4eC5RtuH+Za51Y2+LxBwqi0bZMWZPP9AFPOI1p4ciEWBbgYLke5OIrsMmOUeMlw1vw== X-Received: by 2002:ac8:25d9:: with SMTP id f25mr1005841qtf.156.1551384899001; Thu, 28 Feb 2019 12:14:59 -0800 (PST) Received: from redhat.com (pool-173-76-246-42.bstnma.fios.verizon.net. [173.76.246.42]) by smtp.gmail.com with ESMTPSA id a3sm14633809qta.21.2019.02.28.12.14.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Feb 2019 12:14:58 -0800 (PST) Date: Thu, 28 Feb 2019 15:14:55 -0500 From: "Michael S. Tsirkin" To: Jakub Kicinski Cc: si-wei liu , "Samudrala, Sridhar" , Siwei Liu , Jiri Pirko , Stephen Hemminger , David Miller , Netdev , virtualization@lists.linux-foundation.org, "Brandeburg, Jesse" , Alexander Duyck , Jason Wang , liran.alon@oracle.com 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) Message-ID: <20190228151349-mutt-send-email-mst@kernel.org> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190228115641.7afe6f09@cakuba.netronome.com> 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:41AM -0800, 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). > > > > 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. OK so it seems that you would be happy with a combination of the module parameter disabling failover completely and renaming primary in kernel? Did I get it right? -- MST