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 3182441B83; Mon, 30 Jan 2023 18:10:30 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C031240DF6; Mon, 30 Jan 2023 18:10:29 +0100 (CET) Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) by mails.dpdk.org (Postfix) with ESMTP id B85C940C35 for ; Mon, 30 Jan 2023 18:10:27 +0100 (CET) Received: by mail-vk1-f179.google.com with SMTP id i38so5688474vkd.0 for ; Mon, 30 Jan 2023 09:10:27 -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=jztJqs8CpPGqw3nuwt1xwV0CZPKSRa6O9cKebqwv2LA=; b=bbG/IGFarw6tsoeOobjwJAa3Hwq4xkk7+Pc0NHofWOnponUhVFkB0jX47FphkD3ef4 qeHXjTOmJe/XbzN5DHfvLfPsQSflisDANFrao/HUlFHeRIP/U6JTvSUuBbCKNCrQeZ49 n6dohEG0N4xwp4Ik+9UoPj15XTPIw+7l6cI4YO0bkTn8nNktPy9kZ45OyEduUxlv7msp +5Dm1yoxDRq9Id7+VzveVbf+O3rQWBOFlxihpDcC5LinyJtNNBG2nAF1RdsSrfRJwVoV CuM+vROY5oVe68w36ztdlN/haoLADmR3G6wq+kgQZxdJ35cYlEyXhvRL3QdOhPyBWZuy wwvA== 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=jztJqs8CpPGqw3nuwt1xwV0CZPKSRa6O9cKebqwv2LA=; b=k+Uu443hod7NZUha9gClX3VrsFUGNUq8SPsMiOQwrqNOF2d2FufOD8Qo/xDQB3SwpB U/21uLJgzriz+uoTkYLPLXXadVuLEP9WL9zZ+w592lJuUei21N2CvIId85JKC18IhwSj 9Dgytg95lwQZnlmq5XdOHyNuHJUmASfQzPoHcW1slO75FuDp6UduUBdplqzk26o84PRK STcNWiOmj8cKzCOftt+AlyHzMaeZjfs6P0T1YB1vs0to5+5r1milTQiTu8uoxZuZ3cpY hpzdqXq9UpsVzTcMtNBsr3+j+yMKVsz40PWk80K/Em9bEq+Foy4iHDqu8HBgJlOHWuRE FNYQ== X-Gm-Message-State: AO0yUKW+4wIbWsINV8Xd/BjYV18FqtUDMN+t31JeQg2//EpnInq0SVCN Atf+N652yIRhLlPQy3WHyBY4hQ8jptJsZrIvQEI= X-Google-Smtp-Source: AK7set+ErNaBUwzbm2ISkA7C422IbKNKvkHmkyu+WY83yHeHmXrVzPD0p5TvgPOVrKKkiVazMXQQJJ7gAT/xa7D8ur4= X-Received: by 2002:a1f:20ca:0:b0:3ea:4be1:4a72 with SMTP id g193-20020a1f20ca000000b003ea4be14a72mr413137vkg.20.1675098626957; Mon, 30 Jan 2023 09:10:26 -0800 (PST) MIME-Version: 1.0 References: <20221221090017.3715030-2-rongweil@nvidia.com> <20230118154447.595231-1-rongweil@nvidia.com> <20230118154447.595231-4-rongweil@nvidia.com> In-Reply-To: From: Jerin Jacob Date: Mon, 30 Jan 2023 22:40:00 +0530 Message-ID: Subject: Re: [PATCH v4 3/3] ethdev: add standby flags for live migration To: Rongwei Liu Cc: "dev@dpdk.org" , Matan Azrad , Slava Ovsiienko , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "stephen@networkplumber.org" , Raslan Darawsheh , Ferruh Yigit , Andrew Rybchenko 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Jan 30, 2023 at 8:17 AM Rongwei Liu wrote: > > Hi Jerin > > BR > Rongwei > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Monday, January 23, 2023 21:20 > > To: Rongwei Liu > > Cc: dev@dpdk.org; Matan Azrad ; Slava Ovsiienko > > ; Ori Kam ; NBU-Contact- > > Thomas Monjalon (EXTERNAL) ; > > stephen@networkplumber.org; Raslan Darawsheh ; > > Ferruh Yigit ; Andrew Rybchenko > > > > Subject: Re: [PATCH v4 3/3] ethdev: add standby flags for live migration > > > > External email: Use caution opening links or attachments > > > > > > On Wed, Jan 18, 2023 at 9:15 PM Rongwei Liu wrote: > > > > > > Some flags are added to the process state API for live migration in > > > order to change the behavior of the flow rules in a standby process. > > > > > > Signed-off-by: Rongwei Liu > > > --- > > > lib/ethdev/rte_ethdev.h | 21 +++++++++++++++++++++ > > > 1 file changed, 21 insertions(+) > > > > > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index > > > 1505396ced..9ae4f426a7 100644 > > > --- a/lib/ethdev/rte_ethdev.h > > > +++ b/lib/ethdev/rte_ethdev.h > > > @@ -2260,6 +2260,27 @@ int rte_eth_dev_owner_get(const uint16_t > > > port_id, __rte_experimental int rte_eth_process_set_role(bool > > > standby, uint32_t flags); > > > > > > +/**@{@name Process role flags > > > + * used when migrating from an application to another one. > > > + * @see rte_eth_process_set_active > > > + */ > > > +/** > > > + * When set on a standby process, ingress flow rules will be > > > +effective > > > + * in active and standby processes, so the ingress traffic may be duplicated. > > > + */ > > > +#define RTE_ETH_PROCESS_FLAG_STANDBY_DUP_FLOW_INGRESS > > RTE_BIT32(0) > > > > > > How to duplicate if action has statefull items for example, > > rte_flow_action_security::security_session -> it store the live pointer > > rte_flow_action_meter::mtr_id; -> MTR object ID created with > > rte_mtr_create() > I agree with you, not all actions can be supported in the active/standby model. IMO, Where ever rules are not standalone (like QUEUE, RSS) etc, It will be architecturally is not possible to migrate with pointers. That's where I have concern generalizing this feature for this ethdev. Also, I don't believe there is any real HW support needed for this. IMO, Having DPDK standard multiprocess can do this by keeping secondary application can migrate, keeping all the SW logic in the primary process by doing the housekeeping in the application. On plus side, it works with pointers too. I am not sure how much housekeeping offload to _HW_ in your case. In my view, it should be generic utils functions to track the flow and installing the rules using rte_flow APIs and keep the scope only for rte_flow. That's just my view. I leave to ethdev maintainers for the rest of the review and decision on this series. > That' why we have return value checking and rollback. > In Nvidia driver doc, we suggested user to start from 'rss/queue/jump' actions. > Meter is possible, at least per my view. > Assume: "meter g_action queue 0 / y_action drop / r_action drop" > Old application: create meter_id 'A' with pre-defined limitation. > New application: create meter_id 'B' which has the same parameters with 'A'. > 1. 1st possible approach: > Hardware duplicates the traffic; old application use meter 'A' and new application uses meter 'B' to control traffic throughputs. > Since traffic is duplicated, so it can go to different meters. > 2. 2nd possible approach: > Meter 'A' and 'B' point to the same hardware resource, and traffic reaches this part first and if green, duplication happens.