From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0C4A745AA0; Wed, 2 Oct 2024 20:31:24 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C3E60402D3; Wed, 2 Oct 2024 20:31:23 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 0ADA9402AF for ; Wed, 2 Oct 2024 20:31:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1727893881; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BvcPQhMDMb6wPcxwCYJ0/oHYxhTfD+eq1IMt6xcmL54=; b=DdU7n1/sc+8IJTjBIN4a8PVTHbi34ThdXa4kVtDFPMGbzE10XYuI1WFgGkt8pKZiE8/Wrm vzZoi3H1aFku74B8LTPn5QBfEl34db5lx16/PdXnr2OuXC0sH+jPQaIsKe9B2dULWbV6Ep 8j08OhXl33l3NN51nrgocEOlw4xLc6Q= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-483-z2lqgFDnNHStKb-dKFLXyw-1; Wed, 02 Oct 2024 14:31:20 -0400 X-MC-Unique: z2lqgFDnNHStKb-dKFLXyw-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2fad296738fso570951fa.1 for ; Wed, 02 Oct 2024 11:31:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727893879; x=1728498679; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BvcPQhMDMb6wPcxwCYJ0/oHYxhTfD+eq1IMt6xcmL54=; b=nopvKYJHsGtdcp/enwL+3CLxR/+F/vKF3Nwgr07ZwVmzG0ePtnvWQ0H/Uukfp1hRy9 VQtsylZdZTsvtiT9SzfY6hkGyxhYprGfigRw71tLuy0qgb4QJpJAEsHunVitsn2PGdb3 PnfLePVeF9qDiu9qmgBxQzJu3/D1GaEd5oi7Q7nr6r/j1qZgwy58ehT2+PmbIGgCQV65 QJsOpj/nh977/kFjoDvrbNZ96Znx+ZHam//hv5llg634JckAU3Wr9x0w7IWgh5an54lL ZvybuUhFVfX+RgP1CjZgBmwmDjC7+EBpCX0zTDUn/Bof7US4DC4sXjzCUN1tG7Ea6+nd soaA== X-Gm-Message-State: AOJu0YzNGSvCG7mAdyLzzf4GIr/89qflWRmETu7mY84gcwgK7g+tKpaE d99WUc7hkwdvLAuAaVo88QbxveF18u1baGm1jcsipLcNqtbRD8NZmwXrdxvZalA+ZK6V7dhCxWW oezCW8jacNITNOuV3BnyayyYarTMQKHM4cSDEYKx+2jbEnifpBW0Y6T5ervzn3z0DDhnx1nuzFH JqTyC7NXlVRgSNZVA= X-Received: by 2002:a2e:be13:0:b0:2f3:f339:e68d with SMTP id 38308e7fff4ca-2fae1013927mr28175171fa.15.1727893878856; Wed, 02 Oct 2024 11:31:18 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHlJqklgwHMRaYGLgR+Ua4ht5DRX6bRbZ+ay3Zf0GY/OpmDOqGIp+zOzyVViSUDmxvYlXOFtKbz2btRQiGFFxE= X-Received: by 2002:a2e:be13:0:b0:2f3:f339:e68d with SMTP id 38308e7fff4ca-2fae1013927mr28175011fa.15.1727893878407; Wed, 02 Oct 2024 11:31:18 -0700 (PDT) MIME-Version: 1.0 References: <20240916123044.2692301-1-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Wed, 2 Oct 2024 20:31:07 +0200 Message-ID: Subject: Re: [PATCH 1/2] eal/linux: fix VFIO hotplug with multiprocess To: Maxime Coquelin , Anatoly Burakov Cc: dev@dpdk.org, Kevin Traynor , Luca Boccassi , "Xueming(Steven) Li" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Sep 17, 2024 at 10:20=E2=80=AFAM Maxime Coquelin wrote: > On 9/16/24 14:30, David Marchand wrote: > > At the moment, if VFIO is not available at DPDK init, it won't be > > available unless a subsequent rte_vfio_enable() is done. > > > > Yet, even if rte_vfio_enable() is called again in primary and secondary > > processes, a secondary process will never get to know that VFIO has bee= n > > enabled in the primary process as the MP requests handler is only > > registered in EAL init. > > > > On the other hand, moving the MP requests handler registration earlier > > in EAL init is ok, as secondary process are supposed to be waiting on > > eal_mcfg_wait_complete() until the primary process calls > > eal_mcfg_complete(). > > > > Move vfio_mp_sync_setup() in rte_vfio_enable(). > > > > Besides, rte_eal_vfio_setup() is useless and its name with a rte_ prefi= x > > is ambiguous as it gives the impression it is an exported/public symbol= . > > Remove it and directly call rte_vfio_enable() where needed. > > > > Signed-off-by: David Marchand > > --- > > lib/eal/linux/eal.c | 18 +----------------- > > lib/eal/linux/eal_vfio.c | 9 ++++++--- > > 2 files changed, 7 insertions(+), 20 deletions(-) > > > > Should it be considered as a fix, and so a candidate for stable? > Or do you think it is too risky to change the behaviour? Cc: stable maintainers (fyi) I don't think it is risky: existing applications which relied on multi process had no choice but to make sure VFIO was properly setup before DPDK init. Yet, a change in behavior impact is always hard to estimate. (same comment for the second patch of the series) --=20 David Marchand