From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 61BD9A04DB; Thu, 15 Oct 2020 10:52:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C43C61DD3C; Thu, 15 Oct 2020 10:52:42 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id 0F5111DD3B for ; Thu, 15 Oct 2020 10:52:40 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (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 862E47F4FD; Thu, 15 Oct 2020 11:52:38 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 862E47F4FD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1602751958; bh=WEZC7gh3vZcD1c/x5exWlwxxIAe4iQJm55lVgKl8ZEQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=JE5qvtyL4f+YOvqe3JNxq8oAEPOW8KZvePITG9Dl9YUK5k9mwN3bOebtJrYhhC28h J9ZowYDiInPYkSLKUO8hmeEyXbQnmeCs+kjTo2AZ0eI4ec3Cz+Wi2V/UaDAUlkmOYA maKBYGLzKQF7jBcG1k7xor1JrkV6xFEOQMN/7DfI= To: Thomas Monjalon , Suanming Mou Cc: Ori Kam , Ferruh Yigit , dev@dpdk.org References: <1601194817-208834-1-git-send-email-suanmingm@nvidia.com> <1602724067-390536-1-git-send-email-suanmingm@nvidia.com> <1602724067-390536-3-git-send-email-suanmingm@nvidia.com> <2847989.Y1bzbvb2tm@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <155cc0b5-d50f-2d5a-d164-27b74ce14493@oktetlabs.ru> Date: Thu, 15 Oct 2020 11:52:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <2847989.Y1bzbvb2tm@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 2/2] ethdev: make rte_flow API thread safe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 10/15/20 11:28 AM, Thomas Monjalon wrote: > 15/10/2020 03:07, Suanming Mou: >> Currently, the rte_flow functions are not defined as thread safe. >> DPDK applications either call the functions in single thread or >> protect any concurrent calling for the rte_flow operations using >> a lock. >> >> For PMDs support the flow operations thread safe natively, the >> redundant protection in application hurts the performance of the >> rte_flow operation functions. >> >> And the restriction of thread safe is not guaranteed for the >> rte_flow functions also limits the applications' expectation. >> >> This feature is going to change the rte_flow functions to be thread >> safe. As different PMDs have different flow operations, some may >> support thread safe already and others may not. For PMDs don't >> support flow thread safe operation, a new lock is defined in ethdev >> in order to protects thread unsafe PMDs from rte_flow level. >> >> A new RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE device flag is added to >> determine whether the PMD supports thread safe flow operation or not. >> For PMDs support thread safe flow operations, set the >> RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE flag, rte_flow level functions will >> skip the thread safe helper lock for these PMDs. Again the rte_flow >> level thread safe lock only works when PMD operation functions are >> not thread safe. >> >> For the PMDs which don't want the default mutex lock, just set the >> flag in the PMD, and add the prefer type of lock in the PMD. Then >> the default mutex lock is easily replaced by the PMD level lock. >> >> The change has no effect on the current DPDK applications. No change >> is required for the current DPDK applications. For the standard posix >> pthread_mutex, if no lock contention with the added rte_flow level >> mutex, the mutex only does the atomic increasing in >> pthread_mutex_lock() and decreasing in >> pthread_mutex_unlock(). No futex() syscall will be involved. >> >> Signed-off-by: Suanming Mou >> Acked-by: Ajit Khaparde >> Acked-by: Ori Kam >> Acked-by: Matan Azrad > Acked-by: Thomas Monjalon Acked-by: Andrew Rybchenko