DPDK usage discussions
 help / color / mirror / Atom feed
From: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
To: Sid ali cherrati <scherrati1@gmail.com>
Cc: Dariusz Sosnowski <dsosnowski@nvidia.com>,
	Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>,
	"users@dpdk.org" <users@dpdk.org>
Subject: Re: DPDK Flow Filtering Not Working as Expected
Date: Tue, 4 Feb 2025 17:41:15 +0000	[thread overview]
Message-ID: <e8708ca5-70a5-4062-ab96-6b733385cfd6@intel.com> (raw)
In-Reply-To: <CALn3+CNWgVyF2RAPxC_UsGJucUsTEV59aDvYVqfAaNGjAwPkDQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]

You can also try with the existing X540-AT2 NIC the following :

- Init NIC with 2 queues

- set the FDIR flow for your particular ip/port to route your packet to 
a queue number, say 1

- Instead of using rte_flow to drop all other packets, use RSS. Rewrite 
the RSS ReTa (see rte_eth_dev_rss_reta_update) with queue id you are not 
going to poll, so in this case with queue id = 0. All ReTa entries will 
be 0, so packets not matched with the FDIR will be assigned to this queue.

- ignore rx on the queue 0

I believe this approach would be better for your particular use case, 
than relying on rte_flow to drop all the traffic, which, as we could 
see, depends on the internal HW implementation.

On 04/02/2025 15:50, Sid ali cherrati wrote:
>
> Hello Vladimir,
>
> Thank you for the clarification.
>
> I'll try using the E810 and provide an update on the issue.
>
> Best regards,
> Ali
>
>
> Le mar. 4 févr. 2025 à 16:41, Medvedkin, Vladimir 
> <vladimir.medvedkin@intel.com> a écrit :
>
>     Hi all,
>
>     The goal that Ali is trying to achieve is not possible with the
>     X540-AT2
>     NIC (as with any other ixgbe NIC). The problem is related to:
>
>     1. The first rule is processed by the FDIR engine
>
>     2. FDIR engine is executed in the HW pipeline almost in the end (just
>     before RSS), i.e. after other filters that we could use to match all
>     other packets (5tuple filter engine in this particular case).
>
>     Therefore my recommendations here would be to use a modern NIC
>     such as
>     E810 to implement the required filtering logic.
>
>     On 04/02/2025 09:28, Dariusz Sosnowski wrote:
>     > Hi,
>     >
>     > Anatoly, Vladimir - Would you be able to help with the issue
>     regarding DROP action not being supported on X540-AT2?
>     >
>     > Best regards,
>     > Dariusz Sosnowski
>     >
>     >> From: Sid ali cherrati <scherrati1@gmail.com>
>     >> Sent: Monday, February 3, 2025 18:12
>     >> To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
>     >> Cc: users@dpdk.org
>     >> Subject: Re: DPDK Flow Filtering Not Working as Expected
>     >>
>     >> External email: Use caution opening links or attachments
>     >>
>     >> Here is a better version of the code :
>     >>
>     <snip>
>     >>
>     >> Le lun. 3 févr. 2025 à 16:00, Dmitry Kozlyuk
>     <mailto:dmitry.kozliuk@gmail.com> a écrit :
>     >> 2025-02-03 14:51 (UTC+0100), Sid ali cherrati:
>     >>> [...]
>     >>> if (!rte_flow_validate(port_id, &attr, pattern, actions, &error)){
>     >>> flow = rte_flow_create(port_id, &attr, pattern, actions, &error);
>     >>> }
>     >>>
>     >>> if(flow != 0){
>     >>> printf("Filed to create drop flow filter \n");
>     >>> return -1;
>     >>> }
>     >>> [...]
>     >>> The issue is that when I implement this, I get an error on the
>     drop filter:
>     >>> "Failed to create rule." Do you have any idea why this might
>     be happening?
>     >> There is no this exact error text in your code or DPDK,
>     >> I assume we're talking about the quoted fragment.
>     >> `flow` is a pointer, the correct error condition is `if (flow
>     == NULL)`,
>     >> so your code probably misinterprets success as error.
>     >> Also `flow` is not assigned if `rte_flow_validate()` returns non-0.
>
>     -- 
>     Regards,
>     Vladimir
>
-- 
Regards,
Vladimir

[-- Attachment #2: Type: text/html, Size: 5959 bytes --]

  reply	other threads:[~2025-02-04 17:41 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 [this message]
2025-01-28 18:47 ` Stephen Hemminger
  -- 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=e8708ca5-70a5-4062-ab96-6b733385cfd6@intel.com \
    --to=vladimir.medvedkin@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=dsosnowski@nvidia.com \
    --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).