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 DAD27A0C4D; Wed, 13 Oct 2021 06:57:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9FD6440150; Wed, 13 Oct 2021 06:57:49 +0200 (CEST) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by mails.dpdk.org (Postfix) with ESMTP id 96D7640142 for ; Wed, 13 Oct 2021 06:57:47 +0200 (CEST) Received: by mail-il1-f169.google.com with SMTP id r9so1313367ile.5 for ; Tue, 12 Oct 2021 21:57: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=ftO1iL8TQJ/qY1xZ3GHIE1KhCWN6CRmNSH/qanGYvKA=; b=XMqMVkEWBIYImz2ooyMczFzWgyBgkhLXfKWkwlMds5yIllGpJDs28kQOSac7S+P4QP zK6MRDaK2GAnWrkBxmGGE0h//Fm13GLWVJYuv99ynWSGigEw024jaMAyn7MJuZAQ5M1v LtnFzsnjZ0+m4ZUO37YSdX8RjSpSKBjXIFJDE= 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=ftO1iL8TQJ/qY1xZ3GHIE1KhCWN6CRmNSH/qanGYvKA=; b=LVKmTZlJMJHKRZacDHkRsKx2aXPs6tsCdPgAuY+drxxTWalu/5HxkBjBhkEYSOlMBc dl6y3uxvWUxzMXemPdJlEsDZq5b1NSySU4FXajwwl1NxrHf/XHNU2INiEoOe7gk2Jhsa kzr5hoNohUleiZfNWv7I0Np6mTOhypxVg5P5SSKfeLMibI+DBgL1Dmn4aTmelsq0igUi B2eYdRptgwXHwugUL51yE1rhEc0pkwGga83yWv0f8KaOHa7769XUuJ0z2DH0sqMQ0Bmg EE0QzqOhV8Vv1dTrQE1UaqSbxuGZHxOExlbd892mzBXSKRNWRdLwrLVX26OsHUoG3sAl YmXQ== X-Gm-Message-State: AOAM533yvkV/st846BQcb3zkEmNvSsHGh5bkVtl938qB+aIWK6PVPWMw lEWGysraQF25hmk/Olhv48gZ1gMWn8zgSo4WsLjWKg== X-Google-Smtp-Source: ABdhPJxWtfy4RccqJ4Px64IGH3uRnSS1hMn1JKC5WbbFm2skruoczA9p8JjPxbRQeDXERp1YjLUXg5NdcOHZLZWfIDE= X-Received: by 2002:a05:6e02:c2f:: with SMTP id q15mr27378494ilg.255.1634101066803; Tue, 12 Oct 2021 21:57:46 -0700 (PDT) MIME-Version: 1.0 References: <20211006044835.3936226-1-akozyrev@nvidia.com> <20211006044835.3936226-4-akozyrev@nvidia.com> In-Reply-To: <20211006044835.3936226-4-akozyrev@nvidia.com> From: Ajit Khaparde Date: Tue, 12 Oct 2021 21:57:30 -0700 Message-ID: To: Alexander Kozyrev Cc: dpdk-dev , Thomas Monjalon , Ori Kam , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , mohammad.abdul.awal@intel.com, Qi Zhang , Jerin Jacob Kollanukkaran Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 3/3] ethdev: add async queue-based flow rules operations 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 Tue, Oct 5, 2021 at 9:49 PM Alexander Kozyrev wrote: > > A new, faster, queue-based flow rules management mechanism is needed for > applications offloading rules inside the datapath. This asynchronous > and lockless mechanism frees the CPU for further packet processing and > reduces the performance impact of the flow rules creation/destruction > on the datapath. Note that queues are not thread-safe and queue-based > operations can be safely invoked without any locks from a single thread. > > The rte_flow_q_flow_create() function enqueues a flow creation to the > requested queue. It benefits from already configured resources and sets > unique values on top of item and action templates. A flow rule is enqueued > on the specified flow queue and offloaded asynchronously to the hardware. > The function returns immediately to spare CPU for further packet > processing. The application must invoke the rte_flow_q_dequeue() function > to complete the flow rule operation offloading, to clear the queue, and to > receive the operation status. The rte_flow_q_flow_destroy() function > enqueues a flow destruction to the requested queue. > > Signed-off-by: Alexander Kozyrev > Suggested-by: Ori Kam > --- > lib/ethdev/rte_flow.h | 288 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 288 insertions(+) > > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h > index ba3204b17e..8cdffd8d2e 100644 > --- a/lib/ethdev/rte_flow.h > +++ b/lib/ethdev/rte_flow.h > @@ -4298,6 +4298,13 @@ struct rte_flow_port_attr { > * Version of the struct layout, should be 0. > */ > uint32_t version; > + /** > + * Number of flow queues to be configured. > + * Flow queues are used for asyncronous flow rule creation/destruction. > + * The order of operations is not guaranteed inside a queue. > + * Flow queues are not thread-safe. > + */ > + uint16_t nb_queues; Will it matter if PMD can create a smaller set of queues? Or may be just one? Should the application set this based on get_infos_get() or some other mechanism? ::::