From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [130.237.48.192]) by dpdk.org (Postfix) with ESMTP id EB49C5F33 for ; Thu, 14 Feb 2019 12:31:27 +0100 (CET) Received: from smtp-3.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-3.sys.kth.se (Postfix) with ESMTP id B0A6456B8; Thu, 14 Feb 2019 12:31:27 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([127.0.0.1]) by smtp-3.sys.kth.se (smtp-3.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WlDGbTHYfnCl; Thu, 14 Feb 2019 12:31:27 +0100 (CET) X-KTH-Auth: barbette [130.237.20.142] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1550143886; bh=inYsJhTEd+T4qBhpRnemgygxr7K3OKZxpJ1x0+qNL0I=; h=To:Cc:From:Subject:Date; b=NCxUcBH5T54cUo03Yv2k0ruMzt12ckbZWKoEYOQaB206zO05y2NcWA8vcCYZ+ciDR fQ3BmkyzmIjSiUG6GSb5SkZreOBaiVyE98x+xj6W7/QcElWR7C0gu+mHOQMfvF2YjB ONp5Y8LF3x+Erd/gvxz+oyElSLDUJl2NOxL2DamY= X-KTH-mail-from: barbette@kth.se Received: from [130.237.20.142] (s2587.it.kth.se [130.237.20.142]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA id 47D9856AF; Thu, 14 Feb 2019 12:31:25 +0100 (CET) To: "dev@dpdk.org" Cc: adrien.mazarguil@6wind.com, Shahaf Shuler From: Tom Barbette Message-ID: <1d2b91ac-8f43-f851-8250-301d2ce41dd0@kth.se> Date: Thu, 14 Feb 2019 12:31:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: [dpdk-dev] rte_flow update support? 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: , X-List-Received-Date: Thu, 14 Feb 2019 11:31:28 -0000 Hi all, Are there plans to add support for modifying rules using the rte_flow API ? The first problem with destroy+create is atomicity. During the process some packets will get lost. Then the second problem is performance. We measured Mellanox CX5 (mlx5 driver) to be able to "update" at best 2K rules/sec, but that drops to 200 rules/sec when updating TC rules ("transfer" rules, to switch packets between VFs). Real support for update should boost those numbers. I saw the ibverbs API backing the mlx5 supports updating the action of a rule. This would already solve a lot of use cases. Eg, changing destination queue(s) of some rules. Given that mlx5 does not support changing global RSS queues without restarting the device, this would also solve re-balancing issue by using rte_flow. Then, beyond updating only the action of a rule, some researchers have shown[1] that updating rules patterns data instead of creating and deleting rules with similar patterns improve drastically the performance. Eg that could be very interesting to accelerate the offloading of OVS's flow cache (5-tuples), or similar setups. Thanks, Tom [1] Turboflow: information rich flow record generation on commodity switches, J Sonchack et al.