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 8299FA0547; Thu, 28 Oct 2021 20:33:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 482C940DDB; Thu, 28 Oct 2021 20:33:49 +0200 (CEST) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) by mails.dpdk.org (Postfix) with ESMTP id C942F4067B for ; Thu, 28 Oct 2021 20:33:47 +0200 (CEST) Received: by mail-io1-f45.google.com with SMTP id n67so9371059iod.9 for ; Thu, 28 Oct 2021 11:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CeHVpSsM/gTLN3mIrvSTtb7yRH57JEWndGfncUKobm0=; b=J4QTJaCmfn9JJ1rg17nmdYBFym4PPUi5BOWixSwk3UnHKRgx1PfQC0yOfzWBXfZN3w uRxofPKCWKg54yDwVKEfJjPUee7YdWvp3anracU241CZIV7PkF+sq1Ha4nfqTh0bD6Qj EQKP2HKCs6nqRZlRHbUlc373mdds1sSXdUEx8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CeHVpSsM/gTLN3mIrvSTtb7yRH57JEWndGfncUKobm0=; b=vTsUtVcsJjNan6N2cMrjrQ4CzDvQQD07wIQatw1bz2jYlXf/Hv5o2bgwU3Eie1zOzT p9MAHTStMxrjEkfZrsaLq8eVnsH67/A5vqHNkSrfAlZkMeFs+2yh/3DjjS7oavYmuYjN Ry8MT+pV9NSBbcMfoT6rkXlT8pXJl6tZecGra2fYoI7Uf7PMj8D4dPTu55YnuC2GiJIs SipcfltmKGAMOm1EjDoZ27mPqUEwAI/3qHahJ6II6XNVYPHYY5wtGj+esCwIT0xqWHMc qJUXn4RC8+271JGcPI/DYQf7hG4nDVy8mDVsE8oulEazK1GP523vqGMHsUwgS1KQYj4w FPTA== X-Gm-Message-State: AOAM531odcgKoKvuJ7str1q+H3NQIWCT+6bufQH3l4T2KRpo98XIM+Hq O5W5NLQqFrbweK3WF738Dl701SehS1cwslMmXwTkiQ== X-Google-Smtp-Source: ABdhPJwrJp8gq5FelVco8c7da3uksg6jXYkr02f0H5iY2x9QcB6rY8Bsnfc9TwXJoWJfM50kMd+53lQuA5KFJMY9ouc= X-Received: by 2002:a05:6602:1410:: with SMTP id t16mr4363078iov.160.1635446027081; Thu, 28 Oct 2021 11:33:47 -0700 (PDT) MIME-Version: 1.0 References: <20211019123722.3414694-1-dkozlyuk@nvidia.com> <20211021063503.3632732-1-dkozlyuk@nvidia.com> <20211021063503.3632732-2-dkozlyuk@nvidia.com> In-Reply-To: <20211021063503.3632732-2-dkozlyuk@nvidia.com> From: Ajit Khaparde Date: Thu, 28 Oct 2021 11:33:31 -0700 Message-ID: To: Dmitry Kozlyuk Cc: dpdk-dev , Ori Kam , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4 1/6] ethdev: add capability to keep flow rules on restart 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 Sender: "dev" On Wed, Oct 20, 2021 at 11:35 PM Dmitry Kozlyuk wrote: > > Previously, it was not specified what happens to the flow rules > when the device is stopped, possibly reconfigured, then started. > If flow rules were kept, it could be convenient for application > developers, because they wouldn't need to save and restore them. > However, due to the number of flows and possible creation rate it is > impractical to save all flow rules in DPDK layer. This means that flow > rules persistence really depends on whether PMD and HW can implement it > efficiently. It can also be limited by the rule item and action types, > and its attributes transfer bit (a combination of an item/action type > and a value of the transfer bit is called a ruel feature). > > Add a device capability bit for PMDs that can keep at least some > of the flow rules across restart. Without this capability behavior > is still unspecified and it is declared that the application must > flush the rules before stopping the device. > Allow the application to test for persistence of rules using > a particular feature by attempting to create a flow rule > using that feature when the device is stopped > and checking for the specific error. > This is logical because if the PMD can to create the flow rule > when the device is not started and use it after the start happens, > it is natural that it can move its internal flow rule object > to the same state when the device is stopped and restore the state > when the device is started. > > Rule persistence across a reconfigurations is not required, > because tracking all the rules and configuration-dependent resources > they use may be infeasible. In case a PMD cannot keep the rules > across reconfiguration, it is allowed just to report an error. > Application must then flush the rules before attempting it. > > Signed-off-by: Dmitry Kozlyuk Acked-by: Ajit Khaparde