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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 BBA93C433E6 for ; Fri, 12 Mar 2021 06:33:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8C70D64F85 for ; Fri, 12 Mar 2021 06:33:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231671AbhCLGck (ORCPT ); Fri, 12 Mar 2021 01:32:40 -0500 Received: from mail.kernel.org ([198.145.29.99]:42520 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231650AbhCLGcP (ORCPT ); Fri, 12 Mar 2021 01:32:15 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C3A8264F7E; Fri, 12 Mar 2021 06:32:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615530735; bh=x7ZS2xlO1VmRSQpQBaH61aAHjBGzV0tZAn3dkwlPL6s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OqZaGeJKWnJXu/p4ez/w4RCY87r5WqEi2oHol6Dit/kMCITyMoGfIs24KCRuJaShb QeMTMiJJBLTnkx74hBZHXL/NDiKSq1oNDU+12I6gJgu0d15WADfGzluVjT+QaZZyBz vkpVbwmNYjkiieLbtP3eDk0bc0SAaENgTiQtFgInsHN93VrptxeSMmmLO1ctEiClj9 vOw2gcEJwqAOnq9CK3+Q6rTMfDK+zXxLtNGLKv0xJRjOlodgpqf9dsRUYJHYN/8lkC ObTh/bcCm6KKyCF38xWuv4IKMTdWQzXTfpcN8MzdlQdmJyY54euJu01ia3X1NWKVor Lfdr2vtOQ9mZg== Date: Fri, 12 Mar 2021 08:32:11 +0200 From: Leon Romanovsky To: Alexander Duyck Cc: Jason Gunthorpe , Bjorn Helgaas , Bjorn Helgaas , Saeed Mahameed , Jakub Kicinski , linux-pci , linux-rdma@vger.kernel.org, Netdev , Don Dutile , Alex Williamson , "David S . Miller" , Greg Kroah-Hartman Subject: Re: [PATCH mlx5-next v7 0/4] Dynamically assign MSI-X vectors count Message-ID: References: <20210311181729.GA2148230@bjorn-Precision-5520> <20210311201929.GN2356281@nvidia.com> <20210311232059.GR2356281@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, Mar 11, 2021 at 06:53:16PM -0800, Alexander Duyck wrote: > On Thu, Mar 11, 2021 at 3:21 PM Jason Gunthorpe wrote: > > > > On Thu, Mar 11, 2021 at 01:49:24PM -0800, Alexander Duyck wrote: > > > > We don't need to invent new locks and new complexity for something > > > > that is trivially solved already. > > > > > > I am not wanting a new lock. What I am wanting is a way to mark the VF > > > as being stale/offline while we are performing the update. With that > > > we would be able to apply similar logic to any changes in the future. > > > > I think we should hold off doing this until someone comes up with HW > > that needs it. The response time here is microseconds, it is not worth > > any complexity <...> > Another way to think of this is that we are essentially pulling a > device back after we have already allocated the VFs and we are > reconfiguring it before pushing it back out for usage. Having a flag > that we could set on the VF device to say it is "under > construction"/modification/"not ready for use" would be quite useful I > would think. It is not simple flag change, but change of PCI state machine, which is far more complex than holding two locks or call to sysfs_create_file in the loop that made Bjorn nervous. I want to remind again that the suggestion here has nothing to do with the real use case of SR-IOV capable devices in the Linux. The flow is: 1. Disable SR-IOV driver autoprobe 2. Create as much as possible VFs 3. Wait for request from the user to get VM 4. Change MSI-X table according to requested in item #3 5. Bind ready to go VF to VM 6. Inform user about VM readiness The destroy flow includes VM destroy and unbind. Let's focus on solutions for real problems instead of trying to solve theoretical cases that are not going to be tested and deployed. Thanks