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 17B3245B3B; Mon, 14 Oct 2024 20:58:31 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A570F402C3; Mon, 14 Oct 2024 20:58:30 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id E934E4026C for ; Mon, 14 Oct 2024 20:58:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728932308; 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=tLRWjKtC0NQGiN/q1zJYic8RwruWqKCCkb0WcEvUUK8=; b=Y3chSrG0LvD1bAnxVXYJ08dbIZGQ3nIPkiVoEE1I9SRt//WNCCOko5+0ADVk5/rVSiZ7T/ 9FNuLOTslFu5jyc2s5A1ZGVlaheWowYdZwjKslVcrV86PvQxDQhsyIYLDSw4c3PWjEzTWD j4w/7KrNY/pUfMM9dM7VFxdIttGcmUA= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-616-z2YUEKukPPOk4UzYbNLANg-1; Mon, 14 Oct 2024 14:58:27 -0400 X-MC-Unique: z2YUEKukPPOk4UzYbNLANg-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-539f1e9fb86so807938e87.0 for ; Mon, 14 Oct 2024 11:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728932306; x=1729537106; 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=tLRWjKtC0NQGiN/q1zJYic8RwruWqKCCkb0WcEvUUK8=; b=xOrpw09qnHp9+vB1QpdVCQJToSFCZFIrHzAZBtKJpC++AXtdUW8L9iToaWt/50zmPq LYcZVdjMmdna7NsQVDWAIm0W5ZvRRy5jCHr58HRyZyFNOzr8+yRWb93lIC6RQ9rd6iej s3u6F6kVE2Vburg+77NsotSU8P2LWD4Al0aUavK7xw1r1rHAYb7lNOflmS1lC2olmnZW WXPM3vPjzdA0mX7yyky0VYn04GzrX8UW2aa4MN2fyiFQvyl0JbS3vLxXuyzh7QRbKvbS HeBkp52DCMkKKQkEG6i6CyCPrpVpEB0nsJr58z1bSVfgu4KTRQLSVEcvPl9f/pUhiqN2 MKBw== X-Gm-Message-State: AOJu0YwPkZiNWb5oB2cctB2D0XY/HKpTRzm3m5gnNtjB5MrLvrHRxSLS lUSgRAuY50foaoDxsxsl27CKV3/GtosDYiQkZ7/16LakQ5boh8ImRcmxe2n6aReSY44VDwut0+m 1fG3No45o9/WvLfAioCxJ90g2oMq08EHscwJH4qP0ygOCgYeBWMGNfuQqIw4sNse950MklRJygx 30UuDdgSpDOOSQcAo= X-Received: by 2002:a05:6512:e91:b0:539:fe02:c1fe with SMTP id 2adb3069b0e04-539fe02c39bmr176443e87.16.1728932305705; Mon, 14 Oct 2024 11:58:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFJCXka6K7nS4GyrzClMs5Em0kqHCBJTYWIfOMPkLBF7dCG3Mcz/Wj0fxqHzAeBEsWiBtdDiO8vcMXgYgbv0Ek= X-Received: by 2002:a05:6512:e91:b0:539:fe02:c1fe with SMTP id 2adb3069b0e04-539fe02c39bmr176430e87.16.1728932305295; Mon, 14 Oct 2024 11:58:25 -0700 (PDT) MIME-Version: 1.0 References: <20240916123044.2692301-1-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Mon, 14 Oct 2024 20:58:13 +0200 Message-ID: Subject: Re: [PATCH 1/2] eal/linux: fix VFIO hotplug with multiprocess To: David Marchand Cc: dev@dpdk.org, Anatoly Burakov , Kevin Traynor , "Mcnamara, John" , Thomas Monjalon , Maxime Coquelin 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: > > 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 > Reviewed-by: Maxime Coquelin Series applied for rc1. Thanks for the review Maxime. --=20 David Marchand