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 7A4754410E; Thu, 30 May 2024 11:47:22 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4D9E440A75; Thu, 30 May 2024 11:47:22 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mails.dpdk.org (Postfix) with ESMTP id C828240608 for ; Thu, 30 May 2024 11:47:20 +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 7CD24339; Thu, 30 May 2024 02:47:44 -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 DD04D3F641; Thu, 30 May 2024 02:47:18 -0700 (PDT) Message-ID: Date: Thu, 30 May 2024 10:47:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 4/4] dts: add test case that utilizes offload to pmd_buffer_scatter Content-Language: en-GB To: Jeremy Spewock Cc: yoan.picchi@foss.arm.com, Honnappa.Nagarahalli@arm.com, paul.szczepanek@arm.com, juraj.linkes@pantheon.tech, probb@iol.unh.edu, wathsala.vithanage@arm.com, thomas@monjalon.net, dev@dpdk.org References: <20240514201436.2496-1-jspewock@iol.unh.edu> <20240514201436.2496-5-jspewock@iol.unh.edu> From: Luca Vizzarro In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 29/05/2024 21:40, Jeremy Spewock wrote: > This is a good thought. I was sort of falling back on the current > assumption that we can only support 2 ports per server in test suites, > but there is nothing that ensures these ports are the first and second > in trestpmd. I think it is probably safer to just modify the MTU of > all ports that testpmd knows of since we just blindly pick the ingress > and egress ports we want to use. I didn't want to at first since the > ideal would be that we have minimal side effects in testing suites so > we wouldn't want to just change the MTU of all ports, but if there > comes a time when this matters in the future (the only one I could > really think of is implementing parallel testing) then we can just > limit what ports are in the scope of testpmd. Well, I had originally proposed to add test-specific port filters, so that a test can say what it wants (and the shells/testpmd could integrate some test awareness). I think it was said that we want to introduce test configuration that could deal with this. With my shell interaction patch this could work nicely too, so instead of doing: TestPmdShell(self.sut_node) We could implement a Protocol in the TestSuite to ensure that self.sut_node is always present for type checking, and pass self: TestPmdShell(self) Similary the core, port filters etc could also be part of the class per type checking. And the underlying shell could just deal with the boilerplate code. This would also spare us from having to manually write lengthy filters in the test suite code. Per-test-case configurations could also be initialised easily at the class-level through a @test decorator as proposed in Juraj's RFC. This could potentially be done at class initialisation while leaving the current API untouched, although it won't work well with other decorators such as @requires. Just food for thought.