From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice Date: Thu, 19 Apr 2018 07:41:03 +0300 Message-ID: <20180419072003-mutt-send-email-mst@kernel.org> References: <54accf73-e6cc-e03f-6a1c-34e1bbd78047@gmail.com> <20180404.133749.1802514210170809419.davem@davemloft.net> <20180408.123207.2294740686493951200.davem@davemloft.net> <1f3af59f-fd64-cc0d-f9eb-668636c52db4@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Siwei Liu , David Miller , David Ahern , Jiri Pirko , si-wei liu , Stephen Hemminger , Alexander Duyck , "Brandeburg, Jesse" , Jakub Kicinski , Jason Wang , Netdev , virtualization@lists.linux-foundation.org, virtio-dev@lists.oasis-open.org To: "Samudrala, Sridhar" Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Content-Disposition: inline In-Reply-To: <1f3af59f-fd64-cc0d-f9eb-668636c52db4@intel.com> List-Id: netdev.vger.kernel.org On Wed, Apr 18, 2018 at 04:33:34PM -0700, Samudrala, Sridhar wrote: > On 4/17/2018 5:26 PM, Siwei Liu wrote: > > I ran this with a few folks offline and gathered some good feedbacks > > that I'd like to share thus revive the discussion. > > > > First of all, as illustrated in the reply below, cloud service > > providers require transparent live migration. Specifically, the main > > target of our case is to support SR-IOV live migration via kernel > > upgrade while keeping the userspace of old distros unmodified. If it's > > because this use case is not appealing enough for the mainline to > > adopt, I will shut up and not continue discussing, although > > technically it's entirely possible (and there's precedent in other > > implementation) to do so to benefit any cloud service providers. > > > > If it's just the implementation of hiding netdev itself needs to be > > improved, such as implementing it as attribute flag or adding linkdump > > API, that's completely fine and we can look into that. However, the > > specific issue needs to be undestood beforehand is to make transparent > > SR-IOV to be able to take over the name (so inherit all the configs) > > from the lower netdev, which needs some games with uevents and name > > space reservation. So far I don't think it's been well discussed. > > > > One thing in particular I'd like to point out is that the 3-netdev > > model currently missed to address the core problem of live migration: > > migration of hardware specific feature/state, for e.g. ethtool configs > > and hardware offloading states. Only general network state (IP > > address, gateway, for eg.) associated with the bypass interface can be > > migrated. As a follow-up work, bypass driver can/should be enhanced to > > save and apply those hardware specific configs before or after > > migration as needed. The transparent 1-netdev model being proposed as > > part of this patch series will be able to solve that problem naturally > > by making all hardware specific configurations go through the central > > bypass driver, such that hardware configurations can be replayed when > > new VF or passthrough gets plugged back in. Although that > > corresponding function hasn't been implemented today, I'd like to > > refresh everyone's mind that is the core problem any live migration > > proposal should have addressed. > > > > If it would make things more clear to defer netdev hiding until all > > functionalities regarding centralizing and replay are implemented, > > we'd take advices like that and move on to implementing those features > > as follow-up patches. Once all needed features get done, we'd resume > > the work for hiding lower netdev at that point. Think it would be the > > best to make everyone understand the big picture in advance before > > going too far. > > I think we should get the 3-netdev model integrated and add any additional > ndo_ops/ethool ops that we would like to support/migrate before looking into > hiding the lower netdevs. Once they are exposed, I don't think we'll be able to hide them - they will be a kernel ABI. Do you think everyone needs to hide the SRIOV device? Or that only some users need this? -- MST