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 8313643D66 for ; Wed, 27 Mar 2024 10:46:01 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F3EFE402CE; Wed, 27 Mar 2024 10:46:00 +0100 (CET) Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by mails.dpdk.org (Postfix) with ESMTP id 88BEB402B2 for ; Wed, 27 Mar 2024 10:45:59 +0100 (CET) Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-29deb7e2f7aso4620321a91.1 for ; Wed, 27 Mar 2024 02:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domainhart-com.20230601.gappssmtp.com; s=20230601; t=1711532758; x=1712137558; 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=OCrhsljb6qQsaHOrHkQ4oyl8ew4rGZr7tDTk/BFiALk=; b=ldahTfhLsPJ1vPSv156H8BNOA6AKdVBVXCSnXPspCHrDCTSMZZ0bV83BkWbSE4aaBG wvNKRiQvjJtkF1BpkvT3P0enxlqfq8cfGBMhTVrYu6ygcv2AtpjgdcMI0bMCQRhNEHqt jvc1MlR6kdcT7tEraS+N8sbXFItgDf0fYQQheCsGbnrSd/8+gSqDo0KFxSLS2jT90jG6 JUkxZ0Vz6rfVMxYkmotWsqYKfBbUCTHwnxmkjGUcfTDfMe3uwGGuB4HTed/U7oRL4+to 1Cpqw2lGnJA7sSPGrhsZycgB4Liy9mV11RHPSod2gBs4CaEBt35ikZXgXj0gvNy23Wbu fg8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711532758; x=1712137558; 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=OCrhsljb6qQsaHOrHkQ4oyl8ew4rGZr7tDTk/BFiALk=; b=TV1HOQTi7jwFZCnBw5ygzSz2vxUPnM9OKkBngkPQw+ERDD2gozBPHVG7uoSJAKYoZ2 NhsFq8SrRUiM4Eh4eZQDZ001CqOTdqytExhA0EozpAq85YViUaeCGlRkoFF7PtOTXKt4 TrFVi33n2TolB4cBpDH9uQ3KWj+EgY02zgrn8ZRp9dsoZwhJI9+SoQCNw/uh3zheg8ra tr2htM1myWIZ6wH3lhgt/6X6H6T6vaKuveWE4DMGQ2tQY+T3fuF0d6Hy/TZ5owEEdbxS nPu217fUNMnnNoC1nHrpCl9zPoTHYGxuyelV3IVnJDUu3r+AsM7i2DQR8L3hrnWFgFOV ACPw== X-Gm-Message-State: AOJu0Yzy9gOkZ8MkiqtM+hCiNLkp1lDFWZIMR4JaGGw9FH5f+Ey8Yyz9 Nl0nq5tDIgxtog3PQ4td5AwYkex3KDC4z0uUIg9HapCl2274Z3Ebe90vTeN/3YgQiSeW/6f2Og2 Z+aYi9O2XrhvGKopPAD5ukcychTvhcclomj2aMQ== X-Google-Smtp-Source: AGHT+IGoOZk0jf5xf26PmGHHeLpzdDYrh84202VXdS2v8IXX/REypcWfLOt+8eNfONlENPGjhRvr7tRU7yz5AOIAoiE= X-Received: by 2002:a17:90a:df0e:b0:29d:dd50:afe with SMTP id gp14-20020a17090adf0e00b0029ddd500afemr516499pjb.30.1711532758487; Wed, 27 Mar 2024 02:45:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tony Hart Date: Wed, 27 Mar 2024 05:45:47 -0400 Message-ID: Subject: Re: RTE_FLOW not matching UDP ports in head fragments? To: Dariusz Sosnowski Cc: "users@dpdk.org" 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 Hi Dariusz, Thanks for looking into this. On Tue, Mar 26, 2024 at 8:57=E2=80=AFAM Dariusz Sosnowski wrote: > > Hi Tony, > > > -----Original Message----- > > From: Tony Hart > > Sent: Thursday, March 21, 2024 18:24 > > To: users@dpdk.org > > Subject: RTE_FLOW not matching UDP ports in head fragments? > > > > > > Using RTE_FLOW (with the asynchronous API) to match UDP packets coming > > from a particular port and destination address. This is on a Nvidia/Me= llanox > > CX6. This works great whilst the packets are not fragmented, however, = when > > the packet is fragmented it does not match. > > I was expecting that it would still match the head fragment since it st= ill > > contains the UDP header and hence the port (obviously I'm not expecting= it to > > match the tail fragment). > > > > Is this intended behavior (looking at the rte_mbuf_ptype code it sugges= ts that > > it is)? > > > > > > In the script below I see the count for the first entry in group 3 incr= ement for > > the non-fragmented case but when the length of the > > (otherwise) same packet is one byte longer than the MTIU, the counter o= f the > > second group 3 entry is incremented instead. > > > > Thanks for any insights, > > Tony > > > > FYI this is using the v24.03-rc2 dpdk release. > > > > port stop all > > flow configure 0 queues_number 1 queues_size 64 counters_number 1000 > > port start all > > > > # PATTERN TEMPLATES > > flow pattern_template 0 create pattern_template_id 0 ingress template e= nd > > flow pattern_template 0 create pattern_template_id 1 ingress template e= th / > > ipv4 dst mask 0xffffffff / udp src mask 0xffff / end > > > > # ACTION TEMPLATES > > flow actions_template 0 create actions_template_id 0 template jump / en= d > > mask jump / end flow actions_template 0 create actions_template_id 1 > > template count / drop / end mask count / drop / end > > > > # TEMPLATE TABLES > > flow template_table 0 create table_id 0 group 0 priority 0 ingress > > rules_number 1 pattern_template 0 actions_template 0 flow template_tabl= e 0 > > create table_id 8 group 3 priority 1 ingress rules_number 100 > > pattern_template 1 actions_template 1 flow template_table 0 create tabl= e_id > > 9 group 3 priority 99 ingress rules_number 1 pattern_template 0 > > actions_template 1 > > > > # GROUP 0 > > flow queue 0 create 0 template_table 0 pattern_template 0 actions_templ= ate > > 0 postpone no pattern end actions jump group 3 / end > > > > # GROUP 3: > > flow queue 0 create 0 template_table 8 pattern_template 0 actions_templ= ate > > 0 postpone no pattern eth / ipv4 dst spec 2.2.3.1 / udp src spec 389 / = end > > actions count / drop / end flow queue 0 create 0 template_table 9 > > pattern_template 0 actions_template 0 postpone no pattern end actions > > count / drop / end > > In this case the first fragment should be matched against the flow rule w= ith ETH / IPV4 / UDP. > I was able to reproduce the issue internally using the commands you provi= ded. > We'll investigate it and let you know. > > Best regards, > Dariusz Sosnowski --=20 tony