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 E2A09460E4 for ; Wed, 29 Jan 2025 09:57:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AD37B40270; Wed, 29 Jan 2025 09:57:16 +0100 (CET) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by mails.dpdk.org (Postfix) with ESMTP id 6E3AE40144 for ; Tue, 28 Jan 2025 17:50:40 +0100 (CET) Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-e3a1cfeb711so8540462276.0 for ; Tue, 28 Jan 2025 08:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738083039; x=1738687839; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=0EIxTO0+406OBPKGqrf3B+VahvXxYTzP1gfNoeClbwc=; b=W7MIDIq/ujUdx2TXR0nQFOJnCO63ncugWmT/elxLcRNpHEcDChhR1OJDyWozxVzOd3 Q7uftz+KozmqPro66UQpjjb43iZ5Idpr64EG60svm8Fn8IOxZ50HkizU2zuaonu/HP1D fy9NOWD4jcjLRRdQ/KUKpuusCuca6k5J1BCIP98FRJ8Zu8TTA0YIUEz4Er+EPE5mMqN5 J4H8HfMr+kGOg7B66vA5h+gmfU5kCzuUa29/whAZBafCwkBBh4GiBLMIttWsz4ZPUSti vFvJzdG7og9Vp1LKqAEqsOtb2V/nSRkfPd4xYh0AWOAfzyGJMBSdvlnMKN7d9FIr+X58 gD4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738083039; x=1738687839; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0EIxTO0+406OBPKGqrf3B+VahvXxYTzP1gfNoeClbwc=; b=W5HFgYs/4IKzPGyaPBHsv5QWdwhnwQpQy4H3gVI4I5ZsJaSSY+ipp1a6i0gEnMNKrE pEzWRXJUgQDFdDyUXM5ZypyCbs5TMO+SyStVG3XmK/HlPUjGmAhyYddvUm1EiPyuvVrH 7d5NRod92cwhtuiqlW7buU2SIYgN8t8+nw+723NTKO43tDy4eJSb5MnWUnE6rfT6Rcn8 jbQDlvodxZ/KqVLwUuX8B5z2Lz4ECkyFskxk4fojzlxykgK3dio6S5a2hzU3NmGr5t6w U2sNx2q+jkg/Dr1awZs1n2GXI79nuxofppFK4sD3QwYVlUDtCS8UcvoqA1ZbX9914CY9 Iw0g== X-Gm-Message-State: AOJu0Yy2zn3iHKSL2fwppZCmRcngWqxTW/vQJrnOi0GUU88ehnOlxs6o rqo3ssHTscy3RgREdpABZxg7fy/2mC2SyM+ID27BivCZsmADYKKt7VyedknftAio39t4+AuW1tZ NmbGJqBx2Rd1ssZJ7uYJ5hS/lfROMPzHzPbo= X-Gm-Gg: ASbGncv9aOAW1LET7jfxcH7WdpU4QFCNGEhN2AMq7n+yiLr8uX+WVT5VjdP34tkwV7e 7KQM1hBp4Qpl2lRbdKkSK5nPDF77O6BNAjd6ZnTBz8Ofd0F4lqwVHQOKWQeqOPSPngt6VFRo= X-Google-Smtp-Source: AGHT+IGBV7FZp9AqBpFn7KioQjO9tcTHezqrMVTNNkx/tfJBm/C52ueSooTtRPzptwKY/6xTl+LycB7205SyDyXMj10= X-Received: by 2002:a25:9e83:0:b0:e58:309b:1b0f with SMTP id 3f1490d57ef6-e58309b1c4bmr12034574276.25.1738083039584; Tue, 28 Jan 2025 08:50:39 -0800 (PST) MIME-Version: 1.0 From: Sid ali cherrati Date: Tue, 28 Jan 2025 17:50:28 +0100 X-Gm-Features: AWEUYZkzuKCJO8m1CYLLitWiQOvSYWVkv9h90C-EaM0AwDy3-iQ4hLYVqpcpoQQ Message-ID: Subject: DPDK Flow Filtering Not Working as Expected To: users@dpdk.org Content-Type: multipart/alternative; boundary="0000000000002a27ca062cc6fe05" X-Mailman-Approved-At: Wed, 29 Jan 2025 09:57:15 +0100 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 --0000000000002a27ca062cc6fe05 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 --0000000000002a27ca062cc6fe05 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 drop all packets except those with a specific IP address an= d UDP port.

I have implemented the following flow filtering rule in m= y code:

<= span style=3D"color:rgb(86,156,214)">int flow_filtering(uint16_t port_id, uint32_t ip_addr, uint16_t udp_port= ) {
struct rte_flow_error error;
struct<= /span> 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(<= /span>&attr, 0, sizeof(struct rte_flow_attr));
attr.= ingress =3D = 1; // R=C3=A8= gle pour le trafic entrant
attr.priority =3D 1000; = // Priorit=C3=A9 haute pour que cette r=C3=A8gle soit appliqu=C3=A9e en pre= mier

// D=C3=A9finir le motif de filtrage= (IP + UDP)
memset(pattern<= /span>, 0, <= span style=3D"color:rgb(86,156,214)">sizeof(pattern= ));

pattern[0= ].type =3D RTE_FLOW_ITEM_TYPE_ETH;

<= /span>// Motif IPv4
= pattern[= 1].type =3D RTE_FLOW_ITEM_TYPE_IPV4;
pattern[1].spec = =3D &(struct <= span style=3D"color:rgb(78,201,176)">rte_flow_item_ipv4){
.hdr =3D {
.dst_addr =3D RTE_BE32(ip_addr), // Adresse IP de dest= ination
}
};
<= div>
pattern[1].mask =3D<= /span> &(struct rte_flow_item= _ipv4){
.hdr =3D {
= .dst_addr =3D RTE_BE32(0xFFFFFFFF), // Masque pour l'adresse IP
}
};

= // Motif UDP
<= div> pattern[2].type<= span style=3D"color:rgb(204,204,204)"> =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 destinati= on
}=
};
<= span style=3D"color:rgb(204,204,204)"> pattern[<= span style=3D"color:rgb(181,206,168)">2].mask =3D &(struct r= te_flow_item_udp){
.hdr =3D {
.dst_port<= /span> =3D <= span style=3D"color:rgb(86,156,214)">RTE_BE16(0xFFFF), // Masque pour le port
}
};

= // Fin du motif
pattern[= 3].type =3D RTE_FLOW_ITEM_TYPE_END;

// D=C3=A9f= inir l'action (accepter le paquet)
memse= t(action, 0, sizeof(action));<= /div>
// 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){
.ind= ex =3D RX_ID, // Envoyer l= es paquets =C3=A0 la file RX_ID
};

// Fin de la liste d&= #39;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) {
p= rintf("Erreur lors de la cr=C3=A9ation de la r=C3=A8g= le de filtrage : %s\n", error.message);
re= turn -1;
}

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

return 0;
= }

However, desp= ite this configuration, I continue to receive packets with other IP address= es and ports that do not match the specified filter.

Could you provid= e any insights into why the filtering isn't working as expected? Any ad= vice on ensuring the rule is properly applied at the hardware level would b= e greatly appreciated.

Thank you for your assistance.

Best rega= rds,

Ali

--0000000000002a27ca062cc6fe05--