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 72C0DA04DD; Fri, 30 Oct 2020 09:59:23 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D2BB472EF; Fri, 30 Oct 2020 09:59:21 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 567E672ED for ; Fri, 30 Oct 2020 09:59:20 +0100 (CET) IronPort-SDR: ui/dTpzqVRDg+0voRNst7CWfveSJk5DTrdk951R3DW6A40LVAYp+RQjgv4QZ/XNTDGXDMqbohh duPFKShImG6w== X-IronPort-AV: E=McAfee;i="6000,8403,9789"; a="230215018" X-IronPort-AV: E=Sophos;i="5.77,432,1596524400"; d="scan'208";a="230215018" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2020 01:59:18 -0700 IronPort-SDR: hnbxW7GhI6X7r8GHydPyJNjJg7OXXotv2973+XuLeNxIKHMfyBnE39gf92MORVs802+TAFhXsi URtitDr41D3g== X-IronPort-AV: E=Sophos;i="5.77,432,1596524400"; d="scan'208";a="536997022" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.23.197]) ([10.252.23.197]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2020 01:59:16 -0700 To: Bing Zhao , Slava Ovsiienko , Matan Azrad , Ori Kam , Thomas Monjalon Cc: "dev@dpdk.org" , Raslan Darawsheh References: <1602255678-108560-1-git-send-email-bingz@nvidia.com> <1603810014-349985-1-git-send-email-bingz@nvidia.com> <1603810014-349985-2-git-send-email-bingz@nvidia.com> <7b7d5f5b-be55-e5f4-9ef9-3628c2008b52@intel.com> From: Ferruh Yigit Message-ID: <201fbdd1-afa7-4f9d-786f-387b7e4220bd@intel.com> Date: Fri, 30 Oct 2020 08:59:12 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2 2/2] net/mlx5: add flow sync API 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/30/2020 5:37 AM, Bing Zhao wrote: > Hi Ferruh, > Thanks for your comments. > PSB > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Friday, October 30, 2020 6:43 AM >> To: Slava Ovsiienko ; Bing Zhao >> ; Matan Azrad ; Ori Kam >> >> Cc: dev@dpdk.org; Raslan Darawsheh >> Subject: Re: [dpdk-dev] [PATCH v2 2/2] net/mlx5: add flow sync API >> >> External email: Use caution opening links or attachments >> >> >> On 10/27/2020 3:42 PM, Slava Ovsiienko wrote: >>> Hi, Bing >>> >>> Release notes / mlx5 features documentation update? >>> Beside this: >>> Acked-by: Viacheslav Ovsiienko >>> >>>> -----Original Message----- >>>> From: Bing Zhao >>>> Sent: Tuesday, October 27, 2020 16:47 >>>> To: Slava Ovsiienko ; Matan Azrad >>>> ; Ori Kam >>>> Cc: dev@dpdk.org; Raslan Darawsheh >>>> Subject: [PATCH v2 2/2] net/mlx5: add flow sync API >>>> >>>> When creating a flow, the rule itself might not take effort >>>> immediately once the function call returns with success. It would >>>> take some time to let the steering synchronize with the hardware. >>>> >>>> If the application wants the packet to be sent to hit the flow >> after >>>> it is created, this flow sync API can be used to clear the >> steering >>>> HW cache to enforce next packet hits the latest rules. >>>> >>>> For TX, usually the NIC TX domain and/or the FDB domain should be >>>> synchronized depends in which domain the flow is created. >>>> >>>> The application could also try to synchronize the NIC RX and/or >> the >>>> FDB domain for the ingress packets. >>>> >>>> Signed-off-by: Bing Zhao >>>> Acked-by: Ori Kam >> >> <...> >> >>>> @@ -8169,3 +8179,17 @@ int mlx5_alloc_tunnel_hub(struct >>>> mlx5_dev_ctx_shared *sh) >>>> mlx5_free(thub); >>>> return err; >>>> } >>>> + >>>> +int rte_pmd_mlx5_sync_flow(uint16_t port_id, uint32_t domains) { >>>> + struct rte_eth_dev *dev = &rte_eth_devices[port_id]; >>>> + const struct mlx5_flow_driver_ops *fops; >>>> + int ret; >>>> + struct rte_flow_attr attr = { .transfer = 0 }; >>>> + >>>> + fops = flow_get_drv_ops(flow_get_drv_type(dev, &attr)); >>>> + ret = fops->sync_domain(dev, domains, >>>> MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW); >>>> + if (ret > 0) >>>> + ret = -ret; >>>> + return ret; >>>> +} >> >> This is causing build error in the travis [1], I guess this is >> related to the rdma-core version, is the >> 'MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW' check required in the header like >> other usages? >> >> Also 'MLX5DV_' macros seems used in 'mlx5_flow_dv.c', is it expected >> to use it in this file? (just high-level observation, no idea on >> details.) > > I send a fix for this already yesterday, and the issue should be solved. > That fix could be squashed. > http://patches.dpdk.org/patch/82652/ > Got it, let me squash it in the next-net, and I will test again. >> >> [1] >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftr >> avis- >> ci.org%2Fgithub%2Fferruhy%2Fdpdk%2Fjobs%2F740008969&data=04%7C01 >> %7Cbingz%40nvidia.com%7C59346fa41fce41e08cce08d87c5c1667%7C43083d157 >> 27340c1b7db39efd9ccc17a%7C0%7C0%7C637396082238282132%7CUnknown%7CTWF >> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >> 6Mn0%3D%7C1000&sdata=HGY7vbWWR5ZdIikv39IzZAYcdsJq1FvGjuonClJo%2B >> Pc%3D&reserved=0 >> >> >> >> btw, I just recognized that the patch acked with exception, is the >> documentation requested above (with ack) provided? > > This is a quite simple internal API. The usage and the information are listed in the API doxygen comments. > Do I need to list it in the doc? > That is the request from @Slava above.