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 D854CA034C; Wed, 21 Dec 2022 13:45:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BC45E40A7F; Wed, 21 Dec 2022 13:45:28 +0100 (CET) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by mails.dpdk.org (Postfix) with ESMTP id C0D9A40A7A for ; Wed, 21 Dec 2022 13:45:26 +0100 (CET) Received: by mail-vs1-f45.google.com with SMTP id i2so14627840vsc.1 for ; Wed, 21 Dec 2022 04:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DwgtzCn//Lonn0RkjHOkVC1pXRbvlKKORqaEpftuXcw=; b=EXM2+D6k1e790ofpYTSLbE9h4WTymS5wPu+w7W5AREfybaET7i6ooDhWDcatERnnyn LI+1zdp+c/BZqbyoTT0jiREK1B9wAL8zkIyEEuDYrCyigoWefc8+Fpg0fTzPyToUqVeR BQFMqWmU5007ekE2APEzW3RItSwucxkkvnLeMNDkaePaGAPW8dzLsRs+W7dSxTtIw7ov B9EMOb4vYYObeN0XIykelG/pc7O9clf15QIjUeWXEA0cQDbo4Z3Y/z8Inq623XkyF36D LgtTkbj5B0NdD6wMWvbqOe+jl14m73ug+REpzJxJk+mj+rLSHLYp10WztWiuk5QOPOif 5DSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=DwgtzCn//Lonn0RkjHOkVC1pXRbvlKKORqaEpftuXcw=; b=xwLaktp7VFbR0IqyRGCVrRTkbYifijh6f4NstNqesctW2+K5aZhtYe0bcJSoDcysrv 0LHygwRgOi0BZDHVns82MF03ksNBieM5cjRnEW9vsdMr/X4w3jbzg9/wEDjBKVq6fgQQ +CRElbIUKXSL5rg0EJm+OwG/ReCETwzhzervL7B/y6pyRKSynPZo6L3QrBQMLR54cewV /G1eYlhmaVS3XEdPzWGIzMxCYynZ6mNDby1Uk+NvCR+pPYYxsv5xJ3zKNJPIlAAJX0zn yYB86HJTujF6UMuJw+rYF8XiwcfZ8WZb0M84xQStM15wYDBqApq3mRm5nGPKJXehOWs4 yZNA== X-Gm-Message-State: AFqh2kp5ZRm+GbwVFHcUQjL691Y0hpa/v4LKhgEFs3r9cCbi1XtDgF1m sI4ourrlf0SFp4fxDLkrrIbbyX1Sjd68c12494U= X-Google-Smtp-Source: AMrXdXs21eg5v/KYTfcVr6Nt0jZWVHwkFnapjComCzN/OYY92vsekWV5Vp0XxCztqT++c0hd4r+PLLunWQ2V4e+5eH8= X-Received: by 2002:a67:b44a:0:b0:3b2:e6c6:b207 with SMTP id c10-20020a67b44a000000b003b2e6c6b207mr215015vsm.45.1671626725160; Wed, 21 Dec 2022 04:45:25 -0800 (PST) MIME-Version: 1.0 References: <20221205215416.7ac53a55@hermes.local> <20221221090017.3715030-1-rongweil@nvidia.com> <20221221090017.3715030-3-rongweil@nvidia.com> In-Reply-To: From: Jerin Jacob Date: Wed, 21 Dec 2022 18:14:58 +0530 Message-ID: Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby To: Rongwei Liu Cc: Matan Azrad , Slava Ovsiienko , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh 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 Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu wrote: > > Hi Jerin: > > BR > Rongwei > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Wednesday, December 21, 2022 19:00 > > To: Rongwei Liu > > Cc: Matan Azrad ; Slava Ovsiienko > > ; Ori Kam ; NBU-Contact- > > Thomas Monjalon (EXTERNAL) ; Ferruh Yigit > > ; Andrew Rybchenko > > ; dev@dpdk.org; Raslan Darawsheh > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or s= tandby > > > > External email: Use caution opening links or attachments > > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu wrote= : > > > > > > HI Jerin: > > > > > > > Hi Rongwei > > > > > BR > > > Rongwei > > > > > > > -----Original Message----- > > > > From: Jerin Jacob > > > > Sent: Wednesday, December 21, 2022 17:13 > > > > To: Rongwei Liu > > > > Cc: Matan Azrad ; Slava Ovsiienko > > > > ; Ori Kam ; NBU-Contact- > > > > Thomas Monjalon (EXTERNAL) ; Ferruh Yigit > > > > ; Andrew Rybchenko > > > > ; dev@dpdk.org; Raslan Darawsheh > > > > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active > > > > or standby > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu > > wrote: > > > > > > > > > > Users may want to change the DPDK process to different versions > > > > > > > > Different version of DPDK? If there is any ABI change how to suppor= t this? > > > > > > > There is a new member which was introduced into rte_eth_dev_info but = it > > shouldn=E2=80=99t be ABI breaking since using reserved fields. > > > > That is just for rte_eth_dev_info. What about the ABI change in differe= nt > > ethdev structure and rte_flow structures across different DPDK ABI vers= ions. > > > Besides this, there is no other ABI changes dependency. > > Assume there is a DPDK process A running with version v21.11 and plan to = upgrade to > version v22.11. Let' call v22.11 as process B. OK. That's a relief. I understand the use case now. Why not simply use standard DPDK multiprocess model then. Primary process act as server for slow path API. Secondary process can come and go(aka can be updated at runtime) and use as client to update rules via primary-secondray communication mecha= nism. > > Now, process A has been running for long time and has lot of rules config= ured. It' "active" role per this API definition. > Process B starts and it should call this API and set itself to "standby" = role and user can program the flow rules as they want > and different NIC vendors may have different recommendations. Nvidia sugg= ests only program process B with group 0' rules now. > > The user should sync all desired configurations from process A to process= B, and process A starts to yield traffic like "delete all group 0 > rules for Nvidia' NICs" or quit. > After that process B calls this API and set itself to "active" role, now = the hot-upgrade finishes. > > > > > > such as hot upgrade. > > > > > There is a strong requirement to simplify the logic and shorten > > > > > the traffic downtime as much as possible. > > > > > > > > > > This update introduces new rte_eth process role definitions: > > > > > active or standby. > > > > > > > > > > The active role means rules are programmed to HW immediately, and > > > > > no > > > > > > > > Why it has to be specific only to rte_flow rule? If it spedieic to > > > > rte_flow, why it is in rte_eth_process_ name space? > > > For now, this design focuses on the flow rule offloading and traffic > > redirection. > > > When switching process version, it' important to make sure which > > application receives and handles the traffic. > > > > Changing the DPDK version runtime is just beyond rte_flow driver. > > It' not about changing DPDK version but upgrading DPDK from one PMD versi= on to another one. > Does the preceding example answer your question? > > > > > The changing should be effective across all probing eth devices, that= ' why it > > was put under rte_eth_process_ (for all rte_eth_dev) name space. > > > > > > > > Also, if we are moving the standby, What about the rule whose ABI i= s > > > > changed between versions? > > > > > > Like the comments mentioned: " Before role transition, all the rules = set by > > the active process should be flushed first. " > > > > What happens to rte_flow flow handles for existing ones which is creat= ed with > > version X? > > Also What if new version Y has ABI change in rte_flow_pattern and > > rte_flow_action structure? > > > > For me, If DPDK version change is needed, simply reload the application= . This > > API will soon bloat, and it will be a mess if to start handling Differe= nt DPDK > > version which is not ABI compatible at all. > > > Yes, you are right. Reloading the application is the easiest way but it m= ay have a long time > Window that traffic is lost. No traffic arrives at process A or process B= . > We are trying to simplify the reloading logic and minimize the traffic do= wn time as much as possible. > The approach may differentiate hugely between different NIC vendors, so I= think it should be better if > DPDK can provide an abstract API. > > If process A and process B are ABI different, it doesn't matter. > 1. Call this API with process A means older ABI. > 2. Call this API with process B means newer ABI. > It' have process concept and working scope. > > > > > > > > > > > > behavior changed. This is the default state. > > > > > The standby role means rules are queued in the HW. If no active > > > > > roles alive or back to active, the rules are effective immediatel= y. > > > > > > > > > > Signed-off-by: Rongwei Liu