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 781A443E93; Wed, 17 Apr 2024 16:26:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E9C19402AE; Wed, 17 Apr 2024 16:25:59 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mails.dpdk.org (Postfix) with ESMTP id CA86A4003C for ; Wed, 17 Apr 2024 16:25:57 +0200 (CEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 026EC339; Wed, 17 Apr 2024 07:26:25 -0700 (PDT) Received: from [192.168.50.86] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB8BA3F738; Wed, 17 Apr 2024 07:25:54 -0700 (PDT) Message-ID: <68da0ef2-430b-42af-8c1d-026760cfa4f1@arm.com> Date: Wed, 17 Apr 2024 15:25:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/5] dts: add `show port info` command to TestPmdShell Content-Language: en-GB To: =?UTF-8?Q?Juraj_Linke=C5=A1?= Cc: dev@dpdk.org, Jeremy Spewock , Paul Szczepanek References: <20240412111136.3470304-1-luca.vizzarro@arm.com> <20240412111136.3470304-5-luca.vizzarro@arm.com> <4f17ef06-c508-495a-a0f8-a28e9e77a1f9@arm.com> From: Luca Vizzarro In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 17/04/2024 14:22, Juraj Linkeš wrote: >> I agree that it looks much better. I gave it a first attempt to come up >> with a regular expression that is not too complicated and is able to >> match blocks individually. I've noticed that blocks start with: >> >> \n********* Infos for port X ************ >> >> but don't have an actual ending delimiter, unlike for the stats. > > Ah, so that's the difference and the reason. I guess the ending > delimiter is either the start of the next section of the prompt (or > the end of the string). Yes, but it's not as trivial unfortunately. In the current code I am effectively just finding all the start positions and slice. >> I'll >> experiment with some look ahead constructs. The easiest solution is to >> match everything that is not * ([^*]+) but can we be certain that there >> won't be any asterisk in the actual information? > > We can't. But we can be reasonably certain there won't be five > consecutive asterisks, so maybe we can work with that. We can work with that by using look ahead constructs as mentioned, which can be quite intensive. For example: /(?<=\n\*).*?(?=\n\*|$)/gs looks for the start delimiter and for the start of the next block or the end. This works perfectly! But it's performing 9576 steps (!) for just two ports. The current solution only takes 10 steps in total.