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 3250CA04AC for ; Mon, 24 Aug 2020 12:08:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 974891B53; Mon, 24 Aug 2020 12:08:43 +0200 (CEST) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [130.237.48.192]) by dpdk.org (Postfix) with ESMTP id C000DDE3 for ; Mon, 24 Aug 2020 12:08:42 +0200 (CEST) Received: from smtp-3.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-3.sys.kth.se (Postfix) with ESMTP id 9E00E2D77; Mon, 24 Aug 2020 12:08:42 +0200 (CEST) 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 EqSs637NnGLe; Mon, 24 Aug 2020 12:08:41 +0200 (CEST) X-KTH-Auth: barbette [2a02:2788:7c4:37d:2045:c6e8:271a:8ea4] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1598263721; bh=5Udc6fYoWZMPeyoBkxwjg/aeVnLMvHFJtMqA1ZN3cmw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=lFjM6Rd0Sr2oRDVIVzqoQkj9+prz35c72pEiSZSmJFxEOM0dq3uOpUjSz4kNUuV0D 6pes6MjBQe10sgABcItLtPypvPyZfGX6BC3oKYBpsEz5AHuFMSKX0IzPXxKg6Q4sr8 hRkmUY6w00IZLIud6e7Ypr8hqch5Mv0ShbZq8G/U= X-KTH-mail-from: barbette@kth.se Received: from [IPv6:2a02:2788:7c4:37d:2045:c6e8:271a:8ea4] (unknown [IPv6:2a02:2788:7c4:37d:2045:c6e8:271a:8ea4]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA id 64F35910D; Mon, 24 Aug 2020 12:08:40 +0200 (CEST) To: Filip Janiszewski , Pawel Wodkowski Cc: "users@dpdk.org" References: <9a39c4d5-8248-5223-df10-1c25fa1331c0@filipjaniszewski.com> <8c8034d8-4cd5-bd0b-0958-14d08f5ae6e3@kth.se> <2f9d3b69-4fef-b179-6510-2d2d4c23ec02@filipjaniszewski.com> From: Tom Barbette Message-ID: <7e5ebccd-a771-e838-23be-bdf5712f7a44@kth.se> Date: Mon, 24 Aug 2020 12:08:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr Subject: Re: [dpdk-users] Round-robin packet distribution X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" He means bytes. I think some drivers only allow the flexible bytes to start after the actual matching though, eg TCP header. So check for that. I'd contact Sprayer authors to ask how they did it if I were you. Do you have a specific NIC in mind? Mellanox's ones are pretty powerful, it may be worth it to have a PM-to-PM meeting asking about feature, or CC one of the maintainer. Devs do not always look at all mails. Cheers, Tom Le 18/08/2020 à 16:27, Filip Janiszewski a écrit : > Do you mean bit or bytes? 'b' refers to bit, maybe you meant bytes? As > for the network traffic type, we're capturing financial market traffic > over TCP/UDP, nothing really fancy. > > Thanks > > Il 8/18/20 3:50 PM, Pawel Wodkowski ha scritto: >> Flexible payload matching (aka RAW in flow API) works up to first 64b of >> the >> packet - at least in e1000, ixgbe and i40e. >> >> It will be easier if you can provide some details about you network >> traffic. >> >> Paweł >> >> On 18.08.2020 14:40, Filip Janiszewski wrote: >>> Hi, >>> >>> We had a look at that, and decided that it might be a bit too >>> complicated to implement in our SW and will not work in a performant way >>> as we might wish, ideally we're looking for a simple approach even if >>> not ideal.. >>> >>> So, I was wondering if we can get at least a "fair" distribution (no >>> round robin) using rte flow? And BTW, is it even possible to access the >>> checksum from this API using for example the pattern matching with an >>> offset that points to the proper byte location in the packet? (It seems >>> it can't be done without modification to the driver..) >>> >>> Thanks >>> >>> Il 7/25/20 10:28 AM, Tom Barbette ha scritto: >>>> Hi Filip, >>>> >>>> This is not possible, but you may use the idea of Sprayer >>>> (http://www.gta.ufrj.br/ftp/gta/TechReports/SCC18d.pdf) to dispatch >>>> packets randomly (use RSS on the checksum). >>>> >>>> However, in our paper RSS++ >>>> (https://www.diva-portal.org/smash/get/diva2:1371780/FULLTEXT01.pdf) we >>>> show it's nearly always a bad idea because you'll have to share state, >>>> and even for "stateless" function, that leads to a very bad locality in >>>> a firewall as the same rules have to be fetched to L1 to all cores at >>>> the same time when you receive a burst of similar packets. >>>> >>>> Tom >>>> >>>> Le 24/07/2020 à 12:05, Filip Janiszewski a écrit : >>>>> Hi, >>>>> >>>>> Is there a way in DPDK to configure the NIC to distribute the incoming >>>>> packets to multiple queues in a round robin fashion? Without taking >>>>> into >>>>> account the payload/headers or type of packet, just plain round robin >>>>> distribution to multiple queues. >>>>> >>>>> I'm struggling to obtain a fair mechanism using RSS, perhaps the >>>>> rte_flow API can do the trick? Any other suggestion? >>>>> >>>>> Thanks >>>>>