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 3255DA0540 for ; Fri, 8 Jul 2022 09:22:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B07AB40A7B; Fri, 8 Jul 2022 09:22:02 +0200 (CEST) Received: from mail.deltatec.be (mail.deltatec.be [91.183.90.4]) by mails.dpdk.org (Postfix) with ESMTP id D8B3B406B4 for ; Fri, 8 Jul 2022 09:22:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=deltacast.tv; s=AnsUTM; h=MIME-Version:Content-Type:Message-ID:Date:Subject :To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0zWDLKPyKnkE/E58gfEM7YiOBSG0l6LigzwH5jGAAmg=; b=ezNLiorxGQzsZ0LzEI09WlvyoR vTUIwZP43yjtcSDMQvhmb+K51LF3JSMsEo1Nf/88HJqyN2j5wAnefRyZKx8pSnVuXq+T17yYA5K8M 2mlDVLukYThzUrYXs2q/5LHteFA4lByn6SEKrRlIAnyaEh7AZXG0nnTXjzE5+Vf7p4O8=; Received: from [172.16.4.5] (port=33626 helo=W2K19-SVR-5.office.deltatec.net) by mail.deltatec.be with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9iJC-0007RE-1n for users@dpdk.org; Fri, 08 Jul 2022 09:21:51 +0200 Received: from W2K19-SVR-5.office.deltatec.net (172.16.4.5) by W2K19-SVR-5.office.deltatec.net (172.16.4.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 8 Jul 2022 09:21:50 +0200 Received: from W2K19-SVR-5.office.deltatec.net ([::1]) by W2K19-SVR-5.office.deltatec.net ([::1]) with mapi id 15.02.0792.003; Fri, 8 Jul 2022 09:21:50 +0200 X-SASI-Hits: BODYTEXTH_SIZE_10000_LESS 0.000000, BODYTEXTH_SIZE_3000_MORE 0.000000, BODYTEXTP_SIZE_3000_LESS 0.000000, BODY_SIZE_10000_PLUS 0.000000, HTML_70_90 0.100000, NO_CTA_URI_FOUND 0.000000, NO_FUR_HEADER 0.000000, NO_URI_FOUND 0.000000, NO_URI_HTTPS 0.000000, OUTBOUND 0.000000, OUTBOUND_SOPHOS 0.000000, SENDER_NO_AUTH 0.000000, WEBMAIL_SOURCE 0.000000, WEBMAIL_XOIP 0.000000, WEBMAIL_X_IP_HDR 0.000000, __BODY_NO_MAILTO 0.000000, __BODY_TEXT_X4 0.000000, __BULK_NEGATE 0.000000, __COURIER_PHRASE 0.000000, __CT 0.000000, __CTYPE_HAS_BOUNDARY 0.000000, __CTYPE_MULTIPART 0.000000, __CTYPE_MULTIPART_ALT 0.000000, __DQ_NEG_DOMAIN 0.000000, __DQ_NEG_HEUR 0.000000, __DQ_NEG_IP 0.000000, __FROM_DOMAIN_NOT_IN_BODY 0.000000, __FUR_RDNS_SOPHOS 0.000000, __HAS_FROM 0.000000, __HAS_HTML 0.000000, __HAS_MSGID 0.000000, __HAS_XOIP 0.000000, __HTML_BAD_END 0.000000, __HTML_TAG_DIV 0.000000, __MIME_HTML 0.000000, __MIME_TEXT_H 0.000000, __MIME_TEXT_H1 0.000000, __MIME_TEXT_H2 0.000000, __MIME_TEXT_P 0.000000, __MIME_TEXT_P1 0.000000, __MIME_TEXT_P2 0.000000, __MIME_VERSION 0.000000, __MSGID_32HEX 0.000000, __OUTBOUND_SOPHOS_FUR 0.000000, __OUTBOUND_SOPHOS_FUR_IP 0.000000, __OUTBOUND_SOPHOS_FUR_RDNS 0.000000, __PHISH_SPEAR_SUBJECT 0.000000, __PHISH_SPEAR_SUBJ_ALERT 0.000000, __PHISH_SPEAR_SUBJ_PREDICATE 0.000000, __SANE_MSGID 0.000000, __STYLE_RATWARE_NEG 0.000000, __STYLE_TAG 0.000000, __TAG_EXISTS_HTML 0.000000, __TO_MALFORMED_2 0.000000, __TO_NAME 0.000000, __TO_NO_NAME 0.000000, __URI_NO_MAILTO 0.000000 X-SASI-Probability: 7% X-SASI-RCODE: 200 X-SASI-Version: Antispam-Engine: 4.1.4, AntispamData: 2022.7.8.64520 From: Antoine POLLENUS To: "users@dpdk.org" Subject: Flow filtering issues : not deleted on NIC at time of call rte_flow_destroy Thread-Topic: Flow filtering issues : not deleted on NIC at time of call rte_flow_destroy Thread-Index: AdiSm1ao4gg9hihKQpu06P5xe6ixkQ== Date: Fri, 8 Jul 2022 07:21:50 +0000 Message-ID: Accept-Language: en-US, fr-BE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.6.199] Content-Type: multipart/alternative; boundary="_000_f505e998e2e54b649ffe351b7b884214deltacasttv_" MIME-Version: 1.0 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 --_000_f505e998e2e54b649ffe351b7b884214deltacasttv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, We have some issues with the flow filtering API. When deleting a filter, just after rte_flow_destroy, we clear the received = packets by receiving all packet in that mempool. The issue is that the nic still receive packet in that mempool after the rt= e_flow_destroy is done. We than reuse this mempool to receive packet from a different origin, and w= e see that this mempool still have packet from the previous origin. The filter we use is simply a queue one based on the IP and the UDP dst and= src. The questions are: - Is the rte_flow_destroy asynchronous on the NIC ? we see the filter doesn= 't exist anymore in DPDK. - If yes, is there a way to know when the filter is effectively deleted on = the NIC ? - Is there a way to reset the mempool in a clean way without deleting it ? At this stage to avoid this issue the only fix we found is to sleep during = one second after the call of rte_flow_destroy and then receiving the remain= ing packets still present in mempool. Hope I'll find help here, Regards, Antoine Pollenus --_000_f505e998e2e54b649ffe351b7b884214deltacasttv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

We have s= ome issues with the flow filtering API.

When deleting a filter, just after rte_flow_destroy, we clear the received = packets by receiving all packet in that mempool.
The issue is that the nic still receive packet in that mempool after the rt= e_flow_destroy is done.
We than reuse this mempool to receive packet from a different origin, and w= e see that this mempool still have packet from the previous origin.

The filter we use is simply a queue one based on the IP and the UDP dst and= src.

The questions are:
- Is the rte_flow_destroy asynchronous on the NIC ? we see the filter doesn= ’t exist anymore in DPDK.

- If yes, is there a way to know when the filter is eff= ectively deleted on the NIC ?

- Is ther= e a way to reset the mempool in a clean way without deleting it ?

At this s= tage to avoid this issue the only fix we found is to sleep during one secon= d after the call of rte_flow_destroy and then receiving the remaining packe= ts still present in mempool.

Hope I’ll find help here,

Regards,

Antoine Pollenus

--_000_f505e998e2e54b649ffe351b7b884214deltacasttv_--