From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 287C041B9B; Wed, 1 Feb 2023 09:40:53 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 14A03427F5; Wed, 1 Feb 2023 09:40:53 +0100 (CET) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by mails.dpdk.org (Postfix) with ESMTP id 78A924021F for <dev@dpdk.org>; Wed, 1 Feb 2023 09:40:52 +0100 (CET) Received: by mail-vs1-f53.google.com with SMTP id 187so18820413vsv.10 for <dev@dpdk.org>; Wed, 01 Feb 2023 00:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DjLAKJBifQjRHLDnpQaFsVufB0O+O41vqBENBl7MyBI=; b=ZI7p0v7e4Impoi4eFg07UUn6gkmWhVnRQBScjVy/WfhNeyUYYKqIkfPPvOV66vl7D2 Ysavuezru/c5uGQA15MfvASHDjBfXoY6fLuK+XVr8o5CQWkqDu/4qYDqv+78OUlvDe8x NywEPVnjy+4BFhnSNggFu4C5e7Ek6JdoFAunWJQGH3zCV0WEJwddQZOifA6gUo7iQf9o VZ9K4e25fqFgtH7pH2rnPau3+fTt05A82HxC3i1XAhzJHZaEtP1PD4PYjOINY7jeq9fN MYYo0Xw5Y9QN99GeWgXMtBCMLOd+SsG2/iYJsV4zCb2CA1G/NgERohajjjJu3jlShY4Q AVSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=DjLAKJBifQjRHLDnpQaFsVufB0O+O41vqBENBl7MyBI=; b=t0V+rx1P9v1cEvnTOruHlp+AMX8q4TrUhKUyfFpFcu368YBmLgXc7rZZvxpqlJxdeV qcny7gKV4UD+FAAH67TBphP/OGeYqez2nUIWdDgxlJsrBAUkkm73dSTwyU0hb697eeO7 LVLhkvnNzimOtFxP2AdLFUMrINJ+2sVgF/4TXzmAO83ieokdpO1RvJpmT57aC9goNEgP ZhnKBK2BxJzqAhhH7MLRTSRWJnAC+ilQ/lnvfzcQ+lw73L7GWcClMvFeteJD7IUKIVbA HOzOUfv5CUn2J1naEmovddntcaSlBQ4MHdPs/G7SFoGp6Ca9geF9mhxF4pCSMRwCoSyy Wjfg== X-Gm-Message-State: AO0yUKWj7ZRm0emqzpzM2VbTT83z7h3Viy98RLVUpj8bF/MTmOH9aa8x Sn5U5jTMGwR5TV1f/2yez3LqoF0pofP5pU+mfDs= X-Google-Smtp-Source: AK7set9UW2s5rtomyAUCQGuEEMDCiJoGXSG2HAZJHERF7urKhIrwU1Xcn2KFJcNJ60vfqnE6nz+keG59UkSMMtvfRa0= X-Received: by 2002:a05:6102:830:b0:3fe:3011:1976 with SMTP id k16-20020a056102083000b003fe30111976mr314773vsb.52.1675240851775; Wed, 01 Feb 2023 00:40:51 -0800 (PST) MIME-Version: 1.0 References: <20221221090017.3715030-2-rongweil@nvidia.com> <20230118154447.595231-3-rongweil@nvidia.com> <CALBAE1P4d=uQb1gXwmi8wqJn7pB_DNjrOmGuOMBCg3ZpVBFdqQ@mail.gmail.com> <45277384.fMDQidcC6G@thomas> <6b2c3d11-428a-2c69-ddf9-2b3306dacbce@oktetlabs.ru> In-Reply-To: <6b2c3d11-428a-2c69-ddf9-2b3306dacbce@oktetlabs.ru> From: Jerin Jacob <jerinjacobk@gmail.com> Date: Wed, 1 Feb 2023 14:10:25 +0530 Message-ID: <CALBAE1MzMRgsDBTCwjKFTxJtKvzdQOoifbPK25QY5=SmEUprrQ@mail.gmail.com> Subject: Re: [PATCH v4 2/3] ethdev: add standby state for live migration To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> Cc: Thomas Monjalon <thomas@monjalon.net>, Rongwei Liu <rongweil@nvidia.com>, dev@dpdk.org, matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, stephen@networkplumber.org, rasland@nvidia.com, Ferruh Yigit <ferruh.yigit@amd.com>, bruce.richardson@intel.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Wed, Feb 1, 2023 at 1:02 PM Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> wrote: > > On 2/1/23 01:55, Thomas Monjalon wrote: > > 31/01/2023 19:14, Jerin Jacob: > >> On Wed, Jan 18, 2023 at 9:15 PM Rongwei Liu <rongweil@nvidia.com> wrote: > >>> > >>> When a DPDK application must be upgraded, > >>> the traffic downtime should be shortened as much as possible. > >>> During the migration time, the old application may stay alive > >>> while the new application is starting and being configured. > >>> > >>> In order to optimize the switch to the new application, > >>> the old application may need to be aware of the presence > >>> of the new application being prepared. > >>> This is achieved with a new API allowing the user to change the > >>> new application state to standby and active later. > >>> > >>> The added function is trying to apply the new state to all probed > >>> ethdev ports. To make this API simple and easy to use, > >>> the same flags have to be accepted by all devices. > >>> > >>> This is the scenario of operations in the old and new applications: > >>> . device: already configured by the old application > >>> . new: start as active > >>> . new: probe the same device > >> > >> How to probe same device if is already bind to another application? > >> vfio-pci wont allow this. > > > > I missed that part. > > There is no way to share a VFIO device between 2 applications? > > As I understand multi-process shares an VFIO device between > many application. As far as I remember it is just required to > pass corresponding file descriptor to another application. I think, Here, it is two different primary application. Even if it is primary-secondary kind of case, bus or pci driver layer needs fixup, Currently, if we add allow list same PCI device on primary and secondary, the second app start will fail. > > Anyway I fully agree that the patch requires more documentation > in doc/guides/ with the description of live migration theory of > operations. > > >>> . new: set as standby > >>> . new: configure the device > >>> . device: has configurations from old and new applications > >>> . old: clear its device configuration > >>> . device: has only 1 configuration from new application > >>> . new: set as active > >>> . device: downtime for connecting all to the new application > >>> . old: shutdown > > > > > > >