From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2112B45A71 for ; Tue, 1 Oct 2024 01:51:19 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C66B040268; Tue, 1 Oct 2024 01:51:18 +0200 (CEST) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by mails.dpdk.org (Postfix) with ESMTP id 665AB40267 for ; Tue, 1 Oct 2024 01:51:16 +0200 (CEST) Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-6c582ca168fso34847876d6.2 for ; Mon, 30 Sep 2024 16:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727740276; x=1728345076; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rxFPDZyPS55z/wT+G+vEN8d+snjPeM2A0sKvRnB3Ge8=; b=RFCag/ILRERje4s6HlfF/GaiApdcHp9iKALxIuWvLIrIQgb+nS6u+dbPEX91ELYDyy EH66q6ubm4zNqjet7ybmerhL7div4llXIVgM1zbmJOsKzTZSStNCAquHQ05Ov2hF+eZN OaoOqv4TQCoKylXfk+BtZ1v+06ymbYUYPz5yaSObyswUYse3RX2QvY1bXKM4x+Syi5YN B6aOtJn01dm/L3u9ZZwHYZe1HywxQOmwo9M9fpfllJMLvDLDGk4gVFUzfI2P4TrsfeZW 64jf5ioY3gWV+V3NAjEFS8yDAzWFX13MTGT5ixlQuBZ7ezDBHwvTzWVvYyAMez7jkWqB +6RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727740276; x=1728345076; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rxFPDZyPS55z/wT+G+vEN8d+snjPeM2A0sKvRnB3Ge8=; b=aRWm9dA9fcWbgPbEC/joF9E342O4knGBGL0ovJx9WiIsQcXP1uTqudnv7QQ4+QyzIn X+lnWTsFyq6Q1ceqqQFtmOtPdgOULOMYEGLFk/C7lkNUNaPYPtASOZtpoe/vn7PInFdS UOAbNFYEYSDmR2Sd51EVt3aD/QqR+4xvnmtzF60s7wPW+i2ZbpA6KVUR3bEfdEJiFshy ksYJ2VkCOUcyFVw/mvmhhydTzI59Jzuq/N4YKaITaxJKNyd7c6xw+uJ7Oo9v0J40wyVz 3XH81WFK00bL3VOgmgwdTYlXLfxF0q7cVIv1AcCO/PPdGEGTYOgze1C5FAwxsToq5XPp utLA== X-Forwarded-Encrypted: i=1; AJvYcCXdjJnkuj+omCnh4q8KTxPxD8XrWCgNpoa8anYNPYpC9M+pA53RziXkkhNTD0wzIi3bDLOfcg==@dpdk.org X-Gm-Message-State: AOJu0YyPFjTiPtaM11cMHoo+P8x6G42VSjSF3hDpJY5pAmu6ptbXP/NM zZXOBmGrU3XowMdfDjZ2Lun/NjEeA81ZML5JsLovZceqQAOVcVv2WSp5YwjRPMRw2jCHE/hZbyZ +LNf/EgCTreLOq8cQC4SFVP1toIB+EtQX X-Google-Smtp-Source: AGHT+IGnOlkI4NqEGJQLA2LV4dkEdF3mQt+xpNpgYpqeP4nXJm2zfhOOk5hkoCt/qyuJfHKs6FY0DRk5719hau3dEPU= X-Received: by 2002:a05:6214:469f:b0:6cb:495b:8476 with SMTP id 6a1803df08f44-6cb495b86a3mr198934226d6.50.1727740275704; Mon, 30 Sep 2024 16:51:15 -0700 (PDT) MIME-Version: 1.0 References: <20240929091825.1801231-1-getelson@nvidia.com> In-Reply-To: <20240929091825.1801231-1-getelson@nvidia.com> From: Igor Gutorov Date: Tue, 1 Oct 2024 02:50:40 +0300 Message-ID: Subject: Re: net/mlx5 RTE_ETH_RSS_SCTP support To: Gregory Etelson Cc: bingz@nvidia.com, dsosnowski@nvidia.com, matan@nvidia.com, orika@nvidia.com, suanmingm@nvidia.com, users@dpdk.org, viacheslavo@nvidia.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Hello, On Sun, Sep 29, 2024 at 12:18=E2=80=AFPM Gregory Etelson wrote: > > Hello, > > > I'm wondering about SCTP RSS support in MLX5 NICs. > > testpmd does not show ipv4-sctp or ipv6-sctp as supported > > MLX5 hardware does not offload SCTP RSS. > > Regards, > Gregory Thank you for the response! That is unfortunate. Do you think it is possible to achieve something similar to RSS offload using the flow engine? Let me share a bit more about what I'm trying to do. I have a DPDK application that I want to add SCTP deduplication to. One of the challenges is that duplicated packets might have different IP addresses, but identical SCTP layers, causing these duplicates to be steered to different Rx queues (and hence different threads) by the default IP RSS offload. So, I thought I had few options here: - disable RSS (not really an option, unfortunately) - software based (computing RSS hash in software and software steering the packets, or using global lock-free deduplication tables, or so on) - hardware based, where RSS would be performed on SCTP ports only, causing the duplicated packets to be steered to the same Rx queues. This would allow the usage of per thread deduplication tables and eliminate some overhead from the software based approach. Since SCTP RSS offload is not supported, do you think it is possible to "bypass" this limitation? One idea I had is something along these lines: - Build an eth / ipv4 pattern. Where the IP item has the proto_id field unmasked and set to SCTP. This, I'm assuming, effectively matches SCTP traffic. - Build a RAW item for each SCTP src and dst port combination. - Add QUEUE actions to these patterns (with different queues for different src-dst port combinations in the RAW items). That would be 2^32 flow rules, which I'd guess the hardware wouldn't accept that many (haven't checked what the limit is yet). The number of rules could be then reduced by masking some bits in the RAW i= tem. All of this sounds a bit ridiculous to be honest, but nevertheless, do you think this is viable? Any similar ideas / improvements? Perhaps, is there any chance it is possible to perform RSS on flex items? Sincerely, Igor.