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 ABE0C41DEC for ; Sun, 5 Mar 2023 21:46:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 370F940EF0; Sun, 5 Mar 2023 21:46:33 +0100 (CET) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id 5F32140EE5 for ; Sun, 5 Mar 2023 21:46:31 +0100 (CET) Received: by mail-pl1-f172.google.com with SMTP id u5so8152305plq.7 for ; Sun, 05 Mar 2023 12:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; t=1678049190; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=XzYJg2ZpHNyKG7/kpCr7YyO5hWZyeBMXUcrDhg/XtnY=; b=7wIVRkHspKZPbibd6eWoCmOxNor5T9FsdAZZMUCZmWBAjD5Gn2TLLE9oqoqBYiukLK VONVKokl3uaHIbVdX7t3UoSge7SV+mGgOVon+HyT8e16uj/gbwWXP4KEs+UNzkp7PjzD QG+zYPyz5Y4WBET2xjlOVVF1FAVTDMbSbPJeDtgF1OLA3jRDX8NbA4j49GQ3n7/ndYuC THwspr+yyqeoCJTVk9EOqNTtIFuz28Jss6371GUu9jICW/8ViPCaFn7m2Hs3d4dRmIs1 nZQnRUER7JX0DMLtld7mvFkBp6twfSWLwMbb1eYHjCY6Rq1kxfiteELeQWBKdplTHl1i 4bcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678049190; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XzYJg2ZpHNyKG7/kpCr7YyO5hWZyeBMXUcrDhg/XtnY=; b=jaxo0NLTMCnbW82E/IVR47kiRogR0l4i57jUAEKdlFLN1wm3crMKEH+JageH3J73HM DpnO38tax5t8sCr2cj/CpnlneN/EGdcgY0/vjCbv9vT5ZgFZTmh/XiMqSL6FQsQOERz7 S8k1sPi3RF7I+l//oMA87MD8G8FRZXXXQAlo96KO1YAu9c22y5ttlmgECM8BpyaAs/eg Xz3bTP4MkN2jrkAnKaoLI6yJ79/SvUGiGi+32BahYEXd/X2C6OK8ORNB9Y45npa74Awa LkWqWGmijWjEZoM4NiBtUuMtoDh9xPtudDIn079T1g/uUrYPEz3FHrPoc+ufUz1ZKBB3 3UfQ== X-Gm-Message-State: AO0yUKX+djjhjpl4mCewdlgKPP35tHq/c09NyPocouVHiNcgzNivE6aj k07piiAKSmXswpGszhyffVvIqTmwqDLzjauIKRMAXA== X-Google-Smtp-Source: AK7set8mXK3CNHifaeHloOVXqSt/iQppxCgigBrm2YETZgB0bhKOpwmHBPGZ7I8p2jcPFDUCjRxd1Q== X-Received: by 2002:a05:6a20:cb54:b0:cc:289f:9c37 with SMTP id hd20-20020a056a20cb5400b000cc289f9c37mr10570617pzb.7.1678049190391; Sun, 05 Mar 2023 12:46:30 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id k5-20020a635a45000000b004d4547cc0f7sm4929708pgm.18.2023.03.05.12.46.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Mar 2023 12:46:30 -0800 (PST) Date: Sun, 5 Mar 2023 12:46:28 -0800 From: Stephen Hemminger To: Tony Hart Cc: "users@dpdk.org" Subject: Re: rte_flow: no ability to match on packet length? Message-ID: <20230305124628.503423b4@hermes.local> In-Reply-To: References: <5644d4d8-d47b-4a0c-84ec-17ce8d68d922.8b1a23e8-b9b9-4aca-a31a-0d4e4655acbd.eee7240b-6962-4037-97c6-178856ab054b@emailsignatures365.codetwo.com> MIME-Version: 1.0 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 On Tue, 28 Feb 2023 15:12:31 +0000 Tony Hart wrote: > I=E2=80=99m trying to use the Generic Flow API (rte_flow) to match IP pac= kets based on their length (either L2, L3 or L4 lengths). > =C2=A0 > There doesn=E2=80=99t seem to be an item type that explicitly matches bas= ed on length (RTE_FLOW_ITEM_TYPE_x).=C2=A0 So I=E2=80=99ve tried using a ma= sk with RTE_FLOW_ITEM_TYPE_IPV4 to match on the total_length field (and sim= ilar attempt to match on the UDP header dgram_len field) but the NIC I=E2= =80=99m using (mlx5) returns an error (mask enables non supported bits). > =C2=A0 > Am I out of luck, or maybe missing something? > =C2=A0 > Thanks for any insights! > =C2=A0 > I=E2=80=99ve tried, DPDK: 20.11.7 and 22.11.1 >=20 > Tony Hart | Chief Architect > Tony.Hart@corero.com =20 Short answer: yes, you are right there is no generic length match. Longer answer: rte_flow is an API which is meant to provide access to the u= nderlying match features of NIC hardware. Supporting something requires that the HW/F= W can do the match, and that the driver writer has added (and tested) that match. Hopefully the MLX5 experts can help answer what is possible.