DPDK usage discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Sid ali cherrati <scherrati1@gmail.com>
Cc: users@dpdk.org
Subject: Re: DPDK Flow Filtering Not Working as Expected
Date: Tue, 28 Jan 2025 10:47:27 -0800	[thread overview]
Message-ID: <20250128104727.0a1cb988@hermes.local> (raw)
In-Reply-To: <CALn3+CP3vKCjp8vR1Uwki3XaW8Nu04Et5PBdop78Cp48=DhOow@mail.gmail.com>

On Tue, 28 Jan 2025 17:54:40 +0100
Sid ali cherrati <scherrati1@gmail.com> wrote:

> 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ègle
> memset(&attr, 0, sizeof(struct rte_flow_attr));
> attr.ingress = 1; // Règle pour le trafic entrant
> attr.priority = 1000; // Priorité haute pour que cette règle soit appliquée
> en premier
> 
> // Définir le motif de filtrage (IP + UDP)
> memset(pattern, 0, sizeof(pattern));
> 
> pattern[0].type = RTE_FLOW_ITEM_TYPE_ETH;
> 
> // Motif IPv4
> pattern[1].type = RTE_FLOW_ITEM_TYPE_IPV4;
> pattern[1].spec = &(struct rte_flow_item_ipv4){
> .hdr = {
> .dst_addr = RTE_BE32(ip_addr), // Adresse IP de destination
> }
> };
> pattern[1].mask = &(struct rte_flow_item_ipv4){
> .hdr = {
> .dst_addr = RTE_BE32(0xFFFFFFFF), // Masque pour l'adresse IP
> }
> };
> 
> // Motif UDP
> pattern[2].type = RTE_FLOW_ITEM_TYPE_UDP;
> pattern[2].spec = &(struct rte_flow_item_udp){
> .hdr = {
> .dst_port = RTE_BE16(udp_port), // Port de destination
> }
> };
> pattern[2].mask = &(struct rte_flow_item_udp){
> .hdr = {
> .dst_port = RTE_BE16(0xFFFF), // Masque pour le port
> }
> };
> 
> // Fin du motif
> pattern[3].type = RTE_FLOW_ITEM_TYPE_END;
> 
> // Définir l'action (accepter le paquet)
> memset(action, 0, sizeof(action));
> 
> // Envoyer à la file RX_ID
> action[0].type = RTE_FLOW_ACTION_TYPE_QUEUE;
> action[0].conf = &(struct rte_flow_action_queue){
> .index = RX_ID, // Envoyer les paquets à la file RX_ID
> };
> 
> // Fin de la liste d'actions
> action[1].type = RTE_FLOW_ACTION_TYPE_END;
> 
> // Créer la règle de filtrage
> flow = rte_flow_create(port_id, &attr, pattern, action, &error);
> if (flow == NULL) {
> printf("Erreur lors de la création de la règle de filtrage : %s\n", error.
> message);
> return -1;
> }
> 
> // Afficher un message de succès
> printf(
> "Règle de filtrage créee avec succès pour l'IP %u.%u.%u.%u et 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

You need to add a wildcard flow filter (ie match all) with with a drop action.
The default when no matches to any flow is process packet as normal using
default queues.

  parent reply	other threads:[~2025-01-28 18:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 16:54 Sid ali cherrati
2025-01-28 18:46 ` Dmitry Kozlyuk
2025-02-03 13:51   ` Sid ali cherrati
2025-02-03 15:00     ` Dmitry Kozlyuk
2025-02-03 15:05       ` Sid ali cherrati
2025-02-03 17:12         ` Sid ali cherrati
2025-02-04  9:28           ` Dariusz Sosnowski
2025-02-04 15:41             ` Medvedkin, Vladimir
2025-02-04 15:50               ` Sid ali cherrati
2025-02-04 17:41                 ` Medvedkin, Vladimir
2025-01-28 18:47 ` Stephen Hemminger [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-01-28 16:50 Sid ali cherrati

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250128104727.0a1cb988@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=scherrati1@gmail.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).