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 3ECBE466D8 for ; Tue, 6 May 2025 10:15:34 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 10FA440269; Tue, 6 May 2025 10:15:34 +0200 (CEST) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by mails.dpdk.org (Postfix) with ESMTP id A167440150 for ; Tue, 6 May 2025 10:15:32 +0200 (CEST) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-e72a786b1b8so4257116276.1 for ; Tue, 06 May 2025 01:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746519332; x=1747124132; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cnwIty3gqRJtwJHpBjn+0qPqwdntckiQLka5vUcR+Q0=; b=Jz/OTUhnPoRmlBrM1ECTEnVv8UltKZqI0/VoeEmzLn5i62ju08w7+jbCPkMUGF9/fl 8I2tvsZw7h7MqaGiDrhzZpBMqjhL7m3uvQ0PBTnyBCJQR722aiY+f9kd7PSz1ezybPzy ThdKZK1nq904VXxENClG/W9rcOxAuJRvkUVtyGMOKQgFHpcqSpUfhTOTlVelpups50ZM vhYe9xgNh+8iEG6iHSBy1MkDFp+AA5LxYdit+BD8sFcLpDXIJKtEjeAr9+p5cOndEcmO IGKvFcmvnhqVdVWUuWj3WxtAGJs6R4fyT3zSLad6JW0wgCj2jBrWcNCmGmZX7A5CutwI A6zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746519332; x=1747124132; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cnwIty3gqRJtwJHpBjn+0qPqwdntckiQLka5vUcR+Q0=; b=w9MqFTGBEb6vGhSj3cIsteX0pPPDeEh3WgM7xbQ7Vf58yHixviysvSaeIRLEPPHVR/ ZIOM5vcIpgxDHabk1gQ2IJipuoFiRJr0n1IVn36nL1EORXNPbPJJvZD90Ae4LTT9PNgv d3nm7KDyScHYQ+kq4WzFwZ4BBlopevYgvkQovApIcAhzygEq0SuhdJcFYf3R9rHzUMrW uMf6oy9u61Jz4B2wkyGaCY2vODX+ZtymYqw4a5Qi5t8aHamrv0yiaJdMIcarZ/H7ujfy ulyjGLUADBqC1aYeVppHdvkpZi4t5zgt8tvyHXe5fI8AADyGZXWfB/3yu9HvvH4Cwiok iyHg== X-Gm-Message-State: AOJu0YynF2efOJLHsviP2RIdYvJi4c+5GhNIPm19YdkTERksIQ12Luk6 9TZSS5YoDs/yzN68j2EgWGDxdx7AE9WlFwzmiCwGks6p3/N7/Qj5iTPR42kNjWRXdLKOEvK9tpF bEDzPQqreLhbz2ZSw8B5POEqq/XFUAI+fzkY= X-Gm-Gg: ASbGnctlfxIkF4/y/9J6YysOYVJFci5hEZ+PoQo8e2/JxBSJyfyCBHlfXM3VIF/fJQe 0k0TLAO+ehMCwA66itQoa4m2Pc/zospukMa0dc+m2/b0y+ORgmNwc1BwYO0V8uTbGXv04HRdiVc XMsePHB2IjFX1hXSnUO906tO4= X-Google-Smtp-Source: AGHT+IE2C9Z+TbSomfaDZhE/ozmOmgdgRdbUlFHnCbn55RnQhGgkzTeuTyguD7OSQTbu7XKjd+3a0YNTAcujsMWYPVg= X-Received: by 2002:a25:bc85:0:b0:e73:40bb:3304 with SMTP id 3f1490d57ef6-e75bf0446a2mr3361241276.1.1746519331636; Tue, 06 May 2025 01:15:31 -0700 (PDT) MIME-Version: 1.0 From: Sid ali cherrati Date: Tue, 6 May 2025 10:15:20 +0200 X-Gm-Features: ATxdqUEe6WcS_uAF83ZnoO-0d8yDx0AKqMnSOQpedxapsO9NbVuN4d2A3vVP9Wo Message-ID: Subject: Issue with RTE Flow and RSS with i40e on DPDK 24.11 To: users@dpdk.org Content-Type: multipart/alternative; boundary="0000000000005b0e2606347338c2" 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 --0000000000005b0e2606347338c2 Content-Type: text/plain; charset="UTF-8" Dear [Support Team / DPDK Developers / Intel Support], I hope this message finds you well. I'm currently developing a server application based on *DPDK 24.11*, using an *Intel X710 NIC* with the *i40e driver*. In my application, I'm leveraging *RTE Flow* to filter UDP packets based on specific IP addresses and ports. To direct matching traffic, I initially used the *QUEUE action*, but I observed that only one CPU core reaches 100% utilization, while the others remain idle. This indicates that *RSS is being bypassed*, resulting in a processing bottleneck. To address this, I tried replacing the *QUEUE action* with *RSS*, but I encountered the following validation error: *Validation Failure: RSS Queues not supported when pattern specified* This raises a few questions: - Is this a known limitation of the i40e driver or the X710 hardware? - Are there specific pattern constraints that prevent RSS from being used in this context? - Is there a recommended approach to enable per-core packet distribution while still applying fine-grained filtering? Below is a relevant snippet of the flow rule I'm using: int flow_filtering(uint16_t port_id, uint32_t ip_addr, uint16_t udp_port) { struct rte_flow_error error; struct rte_flow_attr attr = { .ingress = 1, .priority = 0 }; struct rte_flow_item pattern[4]; struct rte_flow_action action[2]; struct rte_flow *flow; // Configuration Ethernet memset(pattern, 0, sizeof(pattern)); pattern[0].type = RTE_FLOW_ITEM_TYPE_ETH; // Configuration IPv4 struct rte_flow_item_ipv4 ipv4_spec = { .hdr.dst_addr = RTE_BE32(ip_addr) }; struct rte_flow_item_ipv4 ipv4_mask = { .hdr.dst_addr = RTE_BE32(0xFFFFFFFF) }; pattern[1].type = RTE_FLOW_ITEM_TYPE_IPV4; pattern[1].spec = &ipv4_spec; pattern[1].mask = &ipv4_mask; // Configuration UDP struct rte_flow_item_udp udp_spec = { .hdr.dst_port = RTE_BE16(udp_port) }; struct rte_flow_item_udp udp_mask = { .hdr.dst_port = RTE_BE16(0xFFFF) }; pattern[2].type = RTE_FLOW_ITEM_TYPE_UDP; pattern[2].spec = &udp_spec; pattern[2].mask = &udp_mask; pattern[3].type = RTE_FLOW_ITEM_TYPE_END; // Configuration RSS uint16_t rss_queues[] = {0, 1, 2, 3, 4, 5}; struct rte_flow_action_rss rss_conf = { .func = RTE_ETH_HASH_FUNCTION_DEFAULT, .types = RTE_ETH_RSS_NONFRAG_IPV4_UDP, .key_len = 0, .queue_num = 6, .queue = rss_queues }; action[0].type = RTE_FLOW_ACTION_TYPE_RSS; action[0].conf = &rss_conf; action[1].type = RTE_FLOW_ACTION_TYPE_END; if (rte_flow_validate(port_id, &attr, pattern, action, &error) != 0) { printf("Validation failed: %s\n", error.message); return -1; } flow = rte_flow_create(port_id, &attr, pattern, action, &error); if (flow == NULL) { printf("Error creating flow rule: %s\n", error.message); return -1; } printf("Flow rule created for IP %u.%u.%u.%u and UDP port %u\n", (ip_addr >> 24) & 0xFF, (ip_addr >> 16) & 0xFF, (ip_addr >> 8) & 0xFF, ip_addr & 0xFF, udp_port); return 0; } Any guidance or clarification would be greatly appreciated. Best regards, Sid-Ali --0000000000005b0e2606347338c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear [Support Team / DPDK Developers / Intel Support],<= /p>

I hope this message finds you well.

I'm currently developing a server application based on DPDK = 24.11, using an Intel X710 NIC with the i= 40e driver. In my application, I'm leveraging RTE Flow= to filter UDP packets based on specific IP addresses and ports.

To direct matching traffic, I initially used the QUEUE action, but I observed that only one CPU core reaches 100% utilization, whi= le the others remain idle. This indicates that RSS is being bypasse= d, resulting in a processing bottleneck.

To address this, I tried replacing the QUEUE action wit= h RSS, but I encountered the following validation error:

Validation Failure: RSS Queues not supported when pattern specif= ied

This raises a few questions:

  • Is this a known limitation of the i40e driver or the X710 hardware?

  • Are there specific pattern constraints that prevent RSS from being used = in this context?

  • Is there a recommended approach to enable per-core packet distribution w= hile still applying fine-grained filtering?

Below is a relevant snippet of the flow rule I'm using:

int flow_filtering(uint16_t<=
span style=3D"color:rgb(204,204,204)"> port_id, uint32_t ip_addr=
, uint16_t udp_port) {
    struct r=
te_flow_error error;
    struct rte_flow_attr=
 attr =3D { 
 =
       .ingress =3D 1, <=
/span>
        .priority =3D 0 
<=
span style=3D"color:rgb(204,204,204)">    };
    struct rte_flow_item pattern[4];
=
    struct rte_flow_action action=
[2];<=
/div>
    struct=
 rte_flow *flow;

    // Configuration Eth=
ernet
    memset(pattern=
, 0, sizeof(pattern));
    pattern=
[0].<=
span style=3D"color:rgb(156,220,254)">type =3D RTE_FLOW_ITEM_TYPE_ETH;<=
/span>

    // Configuration IPv4
    struct rte_flow_item_ipv4 ipv4_=
spec =3D { .=
hdr.dst_addr=
 =3D =
RTE_BE32(ip_addr) };
    struct rte_flow_item_ipv4 ipv4_mask =3D { .=
hdr.dst_addr=
 =3D RTE_BE32(0xFFFFFFFF<=
span style=3D"color:rgb(204,204,204)">) };
    p=
attern[1].type =3D RTE_FLOW_ITEM_TYPE_IPV4;
    <=
span style=3D"color:rgb(156,220,254)">pattern[1].spec =3D &ipv4_spec;
    pattern[1<=
span style=3D"color:rgb(204,204,204)">].mask =3D &ipv4_mask;

   =
 // Configuration UDP
    struct =
rte_flow_item_udp udp_spec =3D { .hdr.dst_port =3D RTE_BE16(=
udp_port) };
    struct <=
span style=3D"color:rgb(78,201,176)">rte_flow_item_udp udp=
_mask =3D { =
.hdr.dst_por=
t =3D RTE_BE16(0xFFFF) };
    pattern[2=
].type =3D RTE_FLOW_ITEM_TYPE_UDP;
    pattern[2<=
span style=3D"color:rgb(204,204,204)">].spec =3D &udp_spec;
    pattern[2=
].mask =3D &udp_mask;

   =
 pattern[3].type =
=3D RTE_FLOW_ITEM_TY=
PE_END;

=
    // Configuration RSS
    uint16_t rss_queues[] =3D {0, 1, 2, 3, 4, 5};
    
    struct rte_flow_action_rss <=
span style=3D"color:rgb(156,220,254)">rss_conf =3D<=
span style=3D"color:rgb(204,204,204)"> {
        .func =3D <=
/span>RTE_ETH_HASH_FUNCTION_DEFAULT,
        .types =3D RTE_ETH_RSS_NONFRAG_IPV4=
_UDP,
        .key_len <=
span style=3D"color:rgb(212,212,212)">=3D 0,
        .queue_=
num =3D 6,
   =
     .queue =
=3D rss_queues
    };

    action[0].type =
=3D RTE_FLOW_=
ACTION_TYPE_RSS;
=

    action[0].conf<=
span style=3D"color:rgb(204,204,204)"> =3D &rss_conf;
=

    action[1].type<=
span style=3D"color:rgb(204,204,204)"> =3D RTE_FLOW_ACTION_TYPE_END;

    if (rte_flow_validate(port_id, &<=
/span>attr, pattern=
, action, &error) !=3D 0<=
span style=3D"color:rgb(204,204,204)">) {
        printf("Validation failed: %s\n<=
/span>", error=
.message);
        return -1;
    }
    
    flow =3D rte_flow_create(port_id, &attr, pattern, action, &error);
    if (flow =
=3D=3D NULL) {
        printf("Error creating flow rule: %s\n", error.message);
        return -1;
    }

    printf("Flow rule cre=
ated for IP %u.%u.%u.%u and UDP port %u\n",=

           (ip_addr >> 24) & 0xFF, (ip_addr >> 16) & 0xFF,
           (<=
/span>ip_addr >&=
gt; 8) & 0xFF=
, ip_addr & 0xFF, udp_port);
    return 0;
}

Any guidance or clarification wo= uld be greatly appreciated.

Best regards,

Sid-Ali

--0000000000005b0e2606347338c2--