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 BE43A46140 for ; Tue, 28 Jan 2025 17:54:52 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B32AD40615; Tue, 28 Jan 2025 17:54:52 +0100 (CET) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by mails.dpdk.org (Postfix) with ESMTP id A9BAD40144 for ; Tue, 28 Jan 2025 17:54:51 +0100 (CET) Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-e549be93d5eso10391526276.1 for ; Tue, 28 Jan 2025 08:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738083291; x=1738688091; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=5UdPJW59Za4ZdSliU3UnNXeNZ6ZW/NHffc2J6KvWIe0=; b=Ajn5+81PjNcRrsG++XworpuzXbjpOnJEbuuLbF9hVYksSuiQPxC6o8AdgGhSXwLn48 Jcx4+XNIqI4KsGiK7/R2VBPiPhh+ipHw4fUs1a5RClLLGU13L0MyfzHC5jg+S5kiokZ6 m5YignAwLxsBR3qosJXQIwb8/nFY+QeS7fFNPjAufRwYRf0DHZmuPU6Dn4E7spIl0Gt5 cGk2kEFkWX9UOQs1WNOclp06AoUJPtQdnVEUA9gBh8jd4yxx297rx2vF1czQNdBt1txt CTv9Pp6Suf/MGb0acSir0sD+8NMe3i3pNEH/bwpCrfnpCQuqtSt4dknU8QrsslU8kk9u e2OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738083291; x=1738688091; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5UdPJW59Za4ZdSliU3UnNXeNZ6ZW/NHffc2J6KvWIe0=; b=H5u6PpDaJEaVlmFOUeLtb169hNRSijWJNiesjcYkIvX1YayXSd6RPzvN7NsSgtYZwo pK6Z8lqiU0J5jL9e0gKM0HLpetAy3MxuuDs9K6tDt3tpQW9ZOxquzS5L9qpF0ZohJzFk tBw/xcFKbKOZQXoHrH/t/cY53jul9MXLhUUEP3V0mnh8k5t43vfeh9BvhGpcD2W64jE+ bB4PGrOi7B8nXeN1vGd7o1er4D0R6w5nwLT5LVXAQ+jKaJrR5hSpqRqjNenc6nt3FTpf eZHAdpGq2cX4wWntvSQk9A21zESnjsp0Fy0XfXxYuyoe15kZRj2QL3F6+uAKi7rHPslH v1jQ== X-Gm-Message-State: AOJu0YyYVks7RPGaLCz5ovXkm8PtrGsFQALR8Vn2/7AUoJh8I02F6xCy X61Yowr8X1dnlZih7X6QoLjpg6xTAFdPdnPQpnPFom+bIusn5k3GdTNBNVF432kf+GtGzHq3Ate XnFpWLzu80dKv/mzmk4WfQ1yRuGVowYJk8gw= X-Gm-Gg: ASbGncvO4yh4bgI31mja0Jg5Gda4JaNKrgpFs3rbXSc7BnBfXGPMPc/0aQ2W14jIM+u zlIZU4g3H9QPDSDx6QyORyh4D2+naJFFJMaSyYYnVamWdXlxIV0EgzOKzimwJKP3LNAvcPi4= X-Google-Smtp-Source: AGHT+IFOk0FhgeqBRYph4ntJinOmFzaoNeep409g0iFELy5YBx9RR5NpjsRZpcJ5wDOFtKEI+ZjRrAKu5ZctCfKZG/s= X-Received: by 2002:a05:6902:2312:b0:e57:48ae:147c with SMTP id 3f1490d57ef6-e57b10638acmr34369967276.16.1738083290859; Tue, 28 Jan 2025 08:54:50 -0800 (PST) MIME-Version: 1.0 From: Sid ali cherrati Date: Tue, 28 Jan 2025 17:54:40 +0100 X-Gm-Features: AWEUYZlwLkEqHMwbZz3RZDICYj8E4XvReWDu8DKoSvE_9zS3CsxfAH_N_IwjIT4 Message-ID: Subject: DPDK Flow Filtering Not Working as Expected To: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000244e11062cc70dbe" 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 --000000000000244e11062cc70dbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear DPDK Team, I am attempting to use DPDK's rte_flow API to filter incoming packets at the hardware level. My goal is to drop all packets except those with a specific IP address and UDP port. I have implemented the following flow filtering rule in my code: 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; struct rte_flow_item pattern[4]; // 4 pour inclure END struct rte_flow_action action[2]; struct rte_flow *flow; // Remplir l'attribut de la r=C3=A8gle memset(&attr, 0, sizeof(struct rte_flow_attr)); attr.ingress =3D 1; // R=C3=A8gle pour le trafic entrant attr.priority =3D 1000; // Priorit=C3=A9 haute pour que cette r=C3=A8gle so= it appliqu=C3=A9e en premier // D=C3=A9finir le motif de filtrage (IP + UDP) memset(pattern, 0, sizeof(pattern)); pattern[0].type =3D RTE_FLOW_ITEM_TYPE_ETH; // Motif IPv4 pattern[1].type =3D RTE_FLOW_ITEM_TYPE_IPV4; pattern[1].spec =3D &(struct rte_flow_item_ipv4){ .hdr =3D { .dst_addr =3D RTE_BE32(ip_addr), // Adresse IP de destination } }; pattern[1].mask =3D &(struct rte_flow_item_ipv4){ .hdr =3D { .dst_addr =3D RTE_BE32(0xFFFFFFFF), // Masque pour l'adresse IP } }; // Motif UDP pattern[2].type =3D RTE_FLOW_ITEM_TYPE_UDP; pattern[2].spec =3D &(struct rte_flow_item_udp){ .hdr =3D { .dst_port =3D RTE_BE16(udp_port), // Port de destination } }; pattern[2].mask =3D &(struct rte_flow_item_udp){ .hdr =3D { .dst_port =3D RTE_BE16(0xFFFF), // Masque pour le port } }; // Fin du motif pattern[3].type =3D RTE_FLOW_ITEM_TYPE_END; // D=C3=A9finir l'action (accepter le paquet) memset(action, 0, sizeof(action)); // Envoyer =C3=A0 la file RX_ID action[0].type =3D RTE_FLOW_ACTION_TYPE_QUEUE; action[0].conf =3D &(struct rte_flow_action_queue){ .index =3D RX_ID, // Envoyer les paquets =C3=A0 la file RX_ID }; // Fin de la liste d'actions action[1].type =3D RTE_FLOW_ACTION_TYPE_END; // Cr=C3=A9er la r=C3=A8gle de filtrage flow =3D rte_flow_create(port_id, &attr, pattern, action, &error); if (flow =3D=3D NULL) { printf("Erreur lors de la cr=C3=A9ation de la r=C3=A8gle de filtrage : %s\n= ", error. message); return -1; } // Afficher un message de succ=C3=A8s printf( "R=C3=A8gle de filtrage cr=C3=A9ee avec succ=C3=A8s pour l'IP %u.%u.%u.%u e= t le port %u\n", (ip_addr >> 24) & 0xFF, (ip_addr >> 16) & 0xFF, (ip_addr >> 8) & 0xFF, ip_addr & 0xFF, udp_port ); return 0; } However, despite this configuration, I continue to receive packets with other IP addresses and ports that do not match the specified filter. Could you provide any insights into why the filtering isn't working as expected? Any advice on ensuring the rule is properly applied at the hardware level would be greatly appreciated. Thank you for your assistance. Best regards, Ali --000000000000244e11062cc70dbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear DPDK Team,

I am attempting to use DPDK's= rte_flow API to filter incoming packets at the hardware level. My goal is to=20 drop all packets except those with a specific IP address and UDP port.

<= p>I have implemented the following flow filtering rule in my code:

int flow_filtering(uint16_t port_id, uint32_t ip_addr, uint16_t udp_port) {
struc= t rte_flow_error error;
struct rte_flow_attr = attr;
= struct rte_fl= ow_item pattern[4]; // 4 = pour inclure END
= struct rte_f= low_action action[2];
struct rte_flow *flow;

// Remplir l'attribut de la r=C3=A8gle
<= span style=3D"color:rgb(204,204,204)"> memset(&attr, 0, sizeof(struct rte_flow_attr));
= attr.ingress= =3D = 1; // R=C3=A8gle pou= r le trafic entrant
attr.= priority =3D 1000; // P= riorit=C3=A9 haute pour que cette r=C3=A8gle soit appliqu=C3=A9e en premier=

// D=C3=A9finir le motif de filtrage (IP= + UDP)
= memset(pattern, 0, sizeof(pattern));

p= attern[0].type =3D RTE_FLOW_ITEM_TYPE_ETH;

// Motif IPv4
pattern[1].type =3D RTE_FLOW_ITEM_TYPE_IPV4;
= pattern[= 1].spec =3D &= (struct rte_flow_item_ipv4){
.hdr =3D {
.dst_addr =3D RTE_B= E32(ip_addr)= , // Adresse IP de destination=
}
};
pat= tern[1].mask =3D<= span style=3D"color:rgb(204,204,204)"> &(struct rte_flow_item_ipv4){
.hdr =3D {
.= dst_addr =3D= RTE_BE32(0xFFFFFFFF), // = Masque pour l'adresse IP
}
};

// Motif UDP
pattern[2].type =3D RTE_FLOW_ITEM_TYPE_UDP;
= pattern[= 2].spec =3D &= (struct rte_flow_item_udp){
.hdr =3D {
= .dst_port =3D RTE_BE= 16(udp_port)= , // Port de destination
}
};
pattern[2].mask =3D= &(struct rte_flow_ite= m_udp){
.hdr =3D {
= .dst_port =3D RTE_BE16(0xFFFF),= // Masque pour le port
}
= };

<= span style=3D"color:rgb(106,153,85)">// Fin du motif
pattern[3].type =3D RTE_FLOW_ITEM_TYPE_END;

// D=C3=A9finir l'act= ion (accepter le paquet)
memset(action, 0, sizeof(= action));

// Envoyer =C3=A0 la file RX_ID
action[0= ].type =3D RTE_FLOW_ACTION_TYPE_QUEUE;
<= /span>action[0].conf =3D &(struct rte_flow_action_queue){
.index =3D RX_ID, // Envoyer les paquets = =C3=A0 la file RX_ID
};

// Fin de la liste d'actions=
action[1].type =3D RTE_FLOW_ACTION_TYPE_END<= span style=3D"color:rgb(204,204,204)">;

/= / Cr=C3=A9er la r=C3=A8gle de filtrage
flow<= /span> =3D <= span style=3D"color:rgb(220,220,170)">rte_flow_create(port= _id, &at= tr, pattern,= action, &am= p;error);
if (flow =3D=3D NULL) {
printf("Erreur lors de la cr=C3=A9ation de la r=C3=A8gle de f= iltrage : %s\n", error.message);
return -1;
}

// Afficher un me= ssage de succ=C3=A8s
printf(
"R= =C3=A8gle de filtrage cr=C3=A9ee avec succ=C3=A8s pour l'IP %u.%u.= %u.%u et le = port %u\n&qu= ot;,
(ip_addr >> 24) & 0xFF,
(<= /span>ip_addr >&= gt; 16) & 0xFF,
(ip_addr >> 8) & 0xFF,=
ip_addr & 0xFF,
udp_port
);

return 0;
}

However, despite this configuration, I continue to receive packets with other IP addresses and ports that do not match the specified filter.

Could you provide any insights into why the filtering isn't working as=20 expected? Any advice on ensuring the rule is properly applied at the=20 hardware level would be greatly appreciated.

Thank you for your assis= tance.

Best regards,

Ali

--000000000000244e11062cc70dbe--