From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54CBEC433B4 for ; Tue, 6 Apr 2021 09:32:14 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id D8EFA613C6 for ; Tue, 6 Apr 2021 09:32:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8EFA613C6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4409114102C; Tue, 6 Apr 2021 11:32:13 +0200 (CEST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by mails.dpdk.org (Postfix) with ESMTP id BD22D14100C for ; Tue, 6 Apr 2021 11:32:11 +0200 (CEST) Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FF2LJ1xBvz1BGJj; Tue, 6 Apr 2021 17:30:00 +0800 (CST) Received: from [127.0.0.1] (10.40.190.165) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.498.0; Tue, 6 Apr 2021 17:32:02 +0800 From: fengchengwen To: "orika@nvidia.com" , Ferruh Yigit CC: "dev@dpdk.org" , "humin29@huawei.com" Message-ID: Date: Tue, 6 Apr 2021 17:32:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.40.190.165] X-CFilter-Loop: Reflected Subject: [dpdk-dev] How about public rte flow lock API 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" Hi, Ori and Ferruh Currently, the rte flow API has the lock of flow_ops_mutx default which used when driver hasn't provided mutex protection, it's inner API which was not public, but in hns3 driver there maybe concurrent access driver's rte flow data when doing reset recovery (which occur in intr thread) and upper-layer application calling flow API. We think it's best to use framework's lock mechanism (i.e. flow_ops_mutex), but currently it can't address hns3's requirement (as described above). There maybe three schemes: A) public the rte flow lock API. B) driver direct access the framework's flow_ops_mutex. C) driver adds one new mutex and delcare RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE. we prefer use the scheme A, how about your opinion ? Best regards