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 BD036C43381 for ; Thu, 21 Mar 2019 12:37:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 93144218FD for ; Thu, 21 Mar 2019 12:37:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728210AbfCUMhh (ORCPT ); Thu, 21 Mar 2019 08:37:37 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:44533 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727986AbfCUMhh (ORCPT ); Thu, 21 Mar 2019 08:37:37 -0400 Received: by mail-qt1-f196.google.com with SMTP id w5so1114021qtb.11 for ; Thu, 21 Mar 2019 05:37:36 -0700 (PDT) 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:content-transfer-encoding :in-reply-to; bh=8SgZGRtu/0I3LwfT4sfos9Bd3hbm+PKL6NAqyOGJwJQ=; b=Qip1kWoaiNYuEDdFsCyJu6FGr35mjwRFvxRtiVXDbocrQzEj7gjRbqd3ZXAVckFy1s ENiRJGZfjq3djiyzX2dFQxSPHAwdbGfuwiJiuBNpy00e8uSo9Plnc5GuvAA+BhN+thNO 8c6IuIPavERuKDgwMqj8G2hGC03EIqC7jmrc/emXRUqSd7018JZye3vP3/ZxbHjShKnv NnAMpdZZfpXCnALQJcxmVthfwWpoeRdCwEd9WJPRahwrscjij7Vof0HF+mNm8I5qZ3W0 LBO1BF3m98Aqp30tooOerlXl/hj7xx5AC+CcNPhLKGcIUOvkZ67/uUv7uMn/KtCoiv0K b5rQ== X-Gm-Message-State: APjAAAVjWxfxB8qLKPVOutVms2/uoE3A1vBgELQ26v+6AcTHz3ir9rBd uHJvgrJsiJhYTRpFDAvwhiSM2w== X-Google-Smtp-Source: APXvYqyWbuFe3ajeQTO5C0BurgoS/vtkrVb0hiOuhEL0XiBN8b0WUjZjzznXglc+DmpdOORqn+u6wQ== X-Received: by 2002:a0c:9acc:: with SMTP id k12mr2855951qvf.211.1553171856462; Thu, 21 Mar 2019 05:37:36 -0700 (PDT) Received: from redhat.com ([195.39.71.253]) by smtp.gmail.com with ESMTPSA id p35sm3013096qte.83.2019.03.21.05.37.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Mar 2019 05:37:35 -0700 (PDT) Date: Thu, 21 Mar 2019 08:37:29 -0400 From: "Michael S. Tsirkin" To: Liran Alon Cc: Stephen Hemminger , Si-Wei Liu , Sridhar Samudrala , Alexander Duyck , Jakub Kicinski , Jiri Pirko , David Miller , Netdev , virtualization@lists.linux-foundation.org, boris.ostrovsky@oracle.com, vijay.balakrishna@oracle.com, jfreimann@redhat.com, ogerlitz@mellanox.com, vuhuong@mellanox.com Subject: Re: [summary] virtio network device failover writeup Message-ID: <20190321082532-mutt-send-email-mst@kernel.org> References: <20190319171638-mutt-send-email-mst@kernel.org> <79F5D7C0-BBAA-4F78-9039-27A444970002@oracle.com> <20190320061632-mutt-send-email-mst@kernel.org> <20190320100747-mutt-send-email-mst@kernel.org> <36772E22-7A8F-4C42-A731-398E3204B418@oracle.com> <20190320180641-mutt-send-email-mst@kernel.org> <20190321044920-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Mar 21, 2019 at 12:07:57PM +0200, Liran Alon wrote: > >>>> 2) It brings non-intuitive customer experience. For example, a customer may attempt to analyse connectivity issue by checking the connectivity > >>>> on a net-failover slave (e.g. the VF) but will see no connectivity when in-fact checking the connectivity on the net-failover master netdev shows correct connectivity. > >>>> > >>>> The set of changes I vision to fix our issues are: > >>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. > >>>> (E.g. Configure the net-failover VF slave in some special way). > >>>> 2) Match the virtio-net and the VF based on a PV attribute instead of MAC. (Similar to as done in NetVSC). E.g. Provide a virtio-net interface to get PCI slot where the matching VF will be hot-plugged by hypervisor. > >>>> 3) Have an explicit virtio-net control message to command hypervisor to switch data-path from virtio-net to VF and vice-versa. Instead of relying on intercepting the PCI master enable-bit > >>>> as an indicator on when VF is about to be set up. (Similar to as done in NetVSC). > >>>> > >>>> Is there any clear issue we see regarding the above suggestion? > >>>> > >>>> -Liran > >>> > >>> The issue would be this: how do we avoid conflicting with namespaces > >>> created by users? > >> > >> This is kinda controversial, but maybe separate netns names into 2 groups: hidden and normal. > >> To reference a hidden netns, you need to do it explicitly. > >> Hidden and normal netns names can collide as they will be maintained in different namespaces (Yes I’m overloading the term namespace here…). > > > > Maybe it's an unnamed namespace. Hidden until userspace gives it a name? > > This is also a good idea that will solve the issue. Yes. > > > > >> Does this seems reasonable? > >> > >> -Liran > > > > Reasonable I'd say yes, easy to implement probably no. But maybe I > > missed a trick or two. > > BTW, from a practical point of view, I think that even until we figure out a solution on how to implement this, > it was better to create an kernel auto-generated name (e.g. “kernel_net_failover_slaves") > that will break only userspace workloads that by a very rare-chance have a netns that collides with this then > the breakage we have today for the various userspace components. > > -Liran It seems quite easy to supply that as a module parameter. Do we need two namespaces though? Won't some userspace still be confused by the two slaves sharing the MAC address? -- MST