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 058D0A0032 for ; Wed, 14 Sep 2022 08:54:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C683840151; Wed, 14 Sep 2022 08:54:02 +0200 (CEST) Received: from mail.deltatec.be (mail.deltatec.be [91.183.90.4]) by mails.dpdk.org (Postfix) with ESMTP id 0BF4540141 for ; Wed, 14 Sep 2022 08:54:02 +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=gHHP6gDrnALdbf/UF0YmsSlBlFTGTBirGH2RfpEvI/g=; b=bUKLQLgGqgWMW1DTOcpZeL0EKo DGLd7Wn3eNXBhDxrqiDw0yCnC+Ba7IECrER2xCccFAc55/Jefd3ZW5LYSTHJT5qbQ6WF1gqL8ybDc P4vHlnHH3v8+mL+noNqeZ4Xm2DQmc7UiLef8gbeXNnBbpQcHwPvsJFbWew5Yq6HC5kqk=; Received: from [172.16.4.5] (port=60350 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 1oYMHW-0006JO-33 for users@dpdk.org; Wed, 14 Sep 2022 08:53:59 +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; Wed, 14 Sep 2022 08:53:58 +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; Wed, 14 Sep 2022 08:53:58 +0200 X-SASI-Hits: BODYTEXTH_SIZE_10000_LESS 0.000000, BODYTEXTH_SIZE_3000_MORE 0.000000, BODYTEXTP_SIZE_3000_LESS 0.000000, HTML_50_70 0.100000, NO_CTA_FOUND 0.000000, NO_CTA_URI_FOUND 0.000000, NO_FUR_HEADER 0.000000, NO_URI_FOUND 0.000000, NO_URI_HTTPS 0.000000, OBFU_SHORT_10CHARS 0.500000, 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, __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_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, __RATWARE_SIGNATURE_3_N1 0.000000, __SANE_MSGID 0.000000, __STYLE_RATWARE_NEG 0.000000, __STYLE_TAG 0.000000, __SUBJ_STARTS_S_BRACKETS 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: 9% X-SASI-RCODE: 200 X-SASI-Version: Antispam-Engine: 4.1.4, AntispamData: 2022.9.14.63619 From: Antoine POLLENUS To: "users@dpdk.org" Subject: [MLX5] Tx scheduling strange behavior on connectx6DX Thread-Topic: [MLX5] Tx scheduling strange behavior on connectx6DX Thread-Index: AdjIBsL/2o2CXFdFRh+CETvEarm9Lg== Date: Wed, 14 Sep 2022 06:53:58 +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_c0b54ee3cf6e48f7a45096b417d00a39deltacasttv_" 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_c0b54ee3cf6e48f7a45096b417d00a39deltacasttv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I'm trying to use the TX scheduling feature on a ConnectX-6Dx with latest f= irmware and 21.11 version of DPDK. But I see some strange behavior. When I advise the nic with the timestamp in the dynamic mbuf field the pack= et go out way too early. Time I want : 1662385925567940000 Received time : 1662385925469600500 The time I want is 100ms in the future of when calling rte_tx_burst. When looking at the xstats I see no packet in the past no packets in a too = long future. But as shown below I see tx_pp_sync_lost, tx_pp_missed_interru= pt_errors, tx_pp_rearm_queue_errors Which seems to be a bad behavior. tx_good_packets:83160 tx_good_bytes:528950026 tx_q0_packets:83160 tx_q0_bytes:528950026 rx_multicast_packets:64 rx_multicast_bytes:6318 tx_multicast_packets:66772 tx_multicast_bytes:94358324 tx_phy_packets:66750 rx_phy_packets:64 tx_phy_bytes:94595646 rx_phy_bytes:6318 tx_pp_missed_interrupt_errors:2 tx_pp_rearm_queue_errors:2 tx_pp_jitter:40 tx_pp_sync_lost:1 For information my tx_pp is set to 500. My NIC is locked on PTP with ptp4l = and phc2sys is used to synchronize the system clock Another strange thing is that the data rate and the pacing seams ok but eve= ry packets are too early but constant. Sometimes I also see the tx_pp_wander going really high at the start of the= transition ( more than 30000000). I tried with testpmd and I see no error so it's seams the problem is someth= ing I do that cause the issue. My question is what could cause the errors I see in the xstats, I think it'= s the key to my problem. Could you also explain a bit what those tx_pp xstats represent because even= when looking at the source code it doesn't seems clear. Thank you in advance for your help. Regards, Antoine Pollenus --_000_c0b54ee3cf6e48f7a45096b417d00a39deltacasttv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,
I’m trying to use the TX scheduling feature on a ConnectX-6Dx with la= test firmware and 21.11 version of DPDK.
But I see some strange behavior.

When I advise the nic with the timestamp in the dynamic mbuf field the pack= et go out way too early.

Time I want : 1662385925567940000
Received time : 1662385925469600500

The time I want is 100ms in the future of when calling rte_tx_burst.

When looking at the xstats I see no packet in the past no packets in a too = long future. But as shown below I see tx_pp_sync_lost, tx_pp_missed_interru= pt_errors, tx_pp_rearm_queue_errors

Which see= ms to be a bad behavior.


tx_good_packets:83160

tx_good_b= ytes:528950026

tx_q0_pac= kets:83160

tx_q0_byt= es:528950026

rx_multic= ast_packets:64

rx_multic= ast_bytes:6318

tx_multic= ast_packets:66772

tx_multic= ast_bytes:94358324

tx_phy_pa= ckets:66750

rx_phy_pa= ckets:64

tx_phy_by= tes:94595646

rx_phy_by= tes:6318

tx_pp_mis= sed_interrupt_errors:2

tx_pp_rea= rm_queue_errors:2

tx_pp_jit= ter:40

tx_pp_syn= c_lost:1

For information my tx_pp is set to 500. My NIC is locked on PTP with ptp4l = and phc2sys is used to synchronize the system clock

Another strange thing is that the data rate and the pacing seams ok but eve= ry packets are too early but constant.

Sometimes I also see the tx_pp_wander going really high at the start of the= transition ( more than 30000000).

I tried with testpmd and I see no error so it’s seams the problem is = something I do that cause the issue.

My question is what could cause the errors I see in the xstats, I think it&= #8217;s the key to my problem.

Could you also explain a bit what those tx_pp xstats represent because even= when looking at the source code it doesn’t seems clear.

Thank you in advance for your help.

Regards,

Antoine Pollenus



--_000_c0b54ee3cf6e48f7a45096b417d00a39deltacasttv_--