From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8E192A04B1 for ; Tue, 24 Nov 2020 14:34:57 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CBAA4C910; Tue, 24 Nov 2020 14:34:55 +0100 (CET) Received: from wh10.alp1.flow.ch (wh10.alp1.flow.ch [185.119.84.194]) by dpdk.org (Postfix) with ESMTP id 0A401C90E for ; Tue, 24 Nov 2020 14:34:53 +0100 (CET) Received: from [::1] (port=49120 helo=wh10.alp1.flow.ch) by wh10.alp1.flow.ch with esmtpa (Exim 4.92) (envelope-from ) id 1khYT5-00AI5Z-Uq for users@dpdk.org; Tue, 24 Nov 2020 14:34:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 24 Nov 2020 14:34:51 +0100 From: Alex Kiselev To: users@dpdk.org Message-ID: X-Sender: alex@therouter.net User-Agent: Roundcube Webmail/1.3.8 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh10.alp1.flow.ch X-AntiAbuse: Original Domain - dpdk.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - therouter.net X-Get-Message-Sender-Via: wh10.alp1.flow.ch: authenticated_id: alex@therouter.net X-Authenticated-Sender: wh10.alp1.flow.ch: alex@therouter.net X-Source: X-Source-Args: X-Source-Dir: Subject: [dpdk-users] scheduler issue X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" Hello, I am facing a problem with the scheduler library DPDK 18.11.10 with default scheduler settings (RED is off). It seems like some of the pipes (last time it was 4 out of 600 pipes) start incorrectly dropping most of the traffic after a couple of days of successful work. So far I've checked that there are no mbuf leaks or any other errors in my code and I am sure that traffic enters problematic pipes. Also switching a traffic in the runtime to pipes of another port restores the traffic flow. Ho do I approach debugging this issue? I've added using rte_sched_queue_read_stats(), but it doesn't give me counters that accumulate values (packet drops for example), it gives me some kind of current values and after a couple of seconds those values are reset to zero, so I can say nothing based on that API. I would appreciate any ideas and help. Thanks.