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 --]
next prev parent 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).