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 C75BEA04B1 for ; Tue, 25 Aug 2020 14:18:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 458461C19C; Tue, 25 Aug 2020 14:17:59 +0200 (CEST) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by dpdk.org (Postfix) with ESMTP id 031081C193 for ; Tue, 25 Aug 2020 14:17:57 +0200 (CEST) Received: by mail-lf1-f53.google.com with SMTP id v12so6087803lfo.13 for ; Tue, 25 Aug 2020 05:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=c7YvlfeP4RREWmzjJLmfqKjuy3kM3ZT/UZ7hGYLIlME=; b=RhkloWVNec9mEFQcKZlZYEUyiDvOIoBqAUU0/XPGGL411Ils1TMBnGVbpPMCBYIbma 8PtiBmdsB81Uyf7ghKN64sgWXZ0sIb7ws2i4Z6pIKecp5daHlgiluwN5LhDQxitWAupw Aho6hjyjUSua3ewS48KdDCHL75o+woQBlLPF64ffaL9Bn2AGrBXTVHovvSqw98RXFu// R1FqfQsUp3RiHQcME5zFfbKoqVVgmR9tEgsFtDFWx1cUEpWe5gwflSEBxB63BcJRKC7P GIfdt7T+jtdyjIJM07CB/mpOF2Ho6v5plo82GbBeOGKKUE5s+LN9q1NMegaG44+27Mls MCwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=c7YvlfeP4RREWmzjJLmfqKjuy3kM3ZT/UZ7hGYLIlME=; b=fgd6Nwk2e84oP21HG+BkED1OWEigrLn5yVPq4fCSfoSJCApYUpnXQY9jaXegM55pPO q+8k8NOba+qSvuRXCOkOpyQg6OlEEuC3NlgG4J14ZlcZUbXOye97Z/6jYSlx5ukST5at 6mg/ACWHmzseZ/YgK5Byc86Ak3UqG+5xvcrcgBpLIEyMHBotmRadfMtDHVCiLK9Pa8p4 N4NCYhBl12KgyLaoKdg6JZTd18/sxzjt86BYnt2U/AgCbqrtOlO6fAG+GrdbQDb70FfR 9y9TZbYg+NyyX6fjPUtNwwK+AwhD9veDv36qQUDyG2qdAhiKCCW6gz5MM/4aokG43FF1 gBKw== X-Gm-Message-State: AOAM530r40/QxYCMNmyxaT5yFnL1ofLkIRlmVLgWb9QFB4zcRfxp1sbw qSXahDiDQQWHsGrSVEQrTX6bvM/w9gO+bXWL X-Google-Smtp-Source: ABdhPJxm/yKxE1rccxWNtdGnmT6TtVQ7A2fj1BJPGwQrkUml1DoQ9By+/YP7HPLBXzn5Nut3SFstVw== X-Received: by 2002:ac2:5683:: with SMTP id 3mr4712629lfr.69.1598357877268; Tue, 25 Aug 2020 05:17:57 -0700 (PDT) Received: from [192.168.110.7] ([194.100.60.111]) by smtp.googlemail.com with ESMTPSA id e10sm950016lfs.4.2020.08.25.05.17.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Aug 2020 05:17:56 -0700 (PDT) To: Tom Barbette , Filip Janiszewski 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> <09498ac1-672d-a1e5-f917-d5720e1c90a7@kth.se> From: Pawel Wodkowski Message-ID: Date: Tue, 25 Aug 2020 14:17:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <09498ac1-672d-a1e5-f917-d5720e1c90a7@kth.se> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" Yes, I meant bytes. Thanks Tom. If you deal with encrypted traffic you can use the payload as random data and spread it using flow director. Constructing flow rules is painful process and be prepared that you case might not work if it is not coverd by test scenarios in DTS. Also you will have to read documentation of your NIC to see what kind of flow type it might support. Start from reading https://doc.dpdk.org/guides/prog_guide/rte_flow.html eg Table 12.22 But in my mind, as already mentioned by someone else, I think that randomly spreading packets across different cores might not be a good idea. If you want packets to be spread across all cores in deterministic but even way then easiest would be to use RSS over IP / UDP. As a second iteration I would use Flow director API + IP / UDP rules *without* RAW items. Paweł On 24.08.2020 12:07, Tom Barbette wrote: > 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 >>>>>> >