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 E364642CF8; Mon, 19 Jun 2023 14:20:09 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6FED240E0F; Mon, 19 Jun 2023 14:20:09 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 4EB9A40DF8 for ; Mon, 19 Jun 2023 14:20:08 +0200 (CEST) Received: from [192.168.1.40] (unknown [188.170.81.161]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 3DE6050; Mon, 19 Jun 2023 15:20:06 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 3DE6050 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1687177207; bh=vLv7hd/mTp0af07f1gXfbbLBN8VkkbiWF6bzVmNTKAo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TYrZBvVNRpV6ZokmRVB1pY6zCI0SCQfJv3570kNNnV24/FhCSpexiDV/xH+UMbHGi a9dumJS4cGwqpraQjS4hiwhxHHIkh1/0aOGqcgcHjlo9iwTSr+ILx4G4biYKkqaKWT Q4j2UpuwwO8DydA9KdsVg/oMmF6aNrlOxHdaUhIo= Message-ID: Date: Mon, 19 Jun 2023 15:20:05 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [RFC PATCH v2] ethdev: advertise flow restore in mbuf Content-Language: en-US To: David Marchand , dev@dpdk.org Cc: thomas@monjalon.net, i.maximets@ovn.org, Aman Singh , Yuying Zhang , Matan Azrad , Viacheslav Ovsiienko , Ori Kam , Suanming Mou , David Christensen , Ruifeng Wang , Bruce Richardson , Konstantin Ananyev , Ferruh Yigit References: <20230505103102.2912297-1-david.marchand@redhat.com> <20230615134701.3392784-1-david.marchand@redhat.com> From: Andrew Rybchenko In-Reply-To: <20230615134701.3392784-1-david.marchand@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 6/15/23 16:47, David Marchand wrote: > As reported by Ilya [1], unconditionally calling > rte_flow_get_restore_info() impacts an application performance for drivers > that do not provide this ops. > It could also impact processing of packets that require no call to > rte_flow_get_restore_info() at all. > > Register a dynamic mbuf flag when an application negotiates tunnel > metadata delivery (calling rte_eth_rx_metadata_negotiate() with > RTE_ETH_RX_METADATA_TUNNEL_ID). > > Drivers then advertise that metadata can be extracted by setting this > dynamic flag in each mbuf. > > The application then calls rte_flow_get_restore_info() only when required. > > Link: http://inbox.dpdk.org/dev/5248c2ca-f2a6-3fb0-38b8-7f659bfa40de@ovn.org/ > Signed-off-by: David Marchand > --- > Changes since RFC v1: > - rebased, > - updated vectorized datapath functions for net/mlx5, > - moved dynamic flag register to rte_eth_rx_metadata_negotiate() and > hid rte_flow_restore_info_dynflag_register() into ethdev internals, For ethdev and net/sfc: Acked-by: Andrew Rybchenko