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 51575A0542; Fri, 28 Oct 2022 04:09:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 02A2A40223; Fri, 28 Oct 2022 04:09:29 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id B19CC40146; Fri, 28 Oct 2022 04:09:26 +0200 (CEST) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Mz5T455y7zVjMr; Fri, 28 Oct 2022 10:04:24 +0800 (CST) Received: from kwepemm600004.china.huawei.com (7.193.23.242) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 28 Oct 2022 10:09:14 +0800 Received: from [10.67.103.231] (10.67.103.231) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 28 Oct 2022 10:09:13 +0800 Message-ID: Date: Fri, 28 Oct 2022 10:09:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v4 1/2] app/testpmd: fix vlan offload of rxq To: "Ye, MingjinX" , "dev@dpdk.org" CC: "stable@dpdk.org" , "Zhou, YidingX" , "Singh, Aman Deep" , "Zhang, Yuying" References: <20221026171007.654038-1-mingjinx.ye@intel.com> From: "lihuisong (C)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.231] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected 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 在 2022/10/27 19:02, Ye, MingjinX 写道: > Hi lihuisong, > > This means that queue offloads need to update by recalling dev_configure > and setup target queues. Why not update queue offloads in PMD? > Can you tell me, where is the limitation? According to other Rx/Tx offload configurations, this may not be a limitation. But it seems to create a dependency on user usage. Port VLAN releated offloads are set by ethdev ops. There is no requirement in ehedev layer that this port needs to stopped when set these offloads. Now it depends on user does recall dev_configure and setup queues to update queue offloads because of setting these offloads. > > Thanks, > Mingjin > >> -----Original Message----- >> From: lihuisong (C) >> Sent: 2022年10月26日 17:53 >> To: Ye, MingjinX ; dev@dpdk.org >> Cc: stable@dpdk.org; Zhou, YidingX ; Singh, Aman >> Deep ; Zhang, Yuying >> >> Subject: Re: [PATCH v4 1/2] app/testpmd: fix vlan offload of rxq >> >> >> 在 2022/10/27 1:10, Mingjin Ye 写道: >>> After setting vlan offload in testpmd, the result is not updated to >>> rxq. Therefore, the queue needs to be reconfigured after executing the >>> "vlan offload" related commands. >>> >>> Fixes: a47aa8b97afe ("app/testpmd: add vlan offload support") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Mingjin Ye >>> --- >>> app/test-pmd/cmdline.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index >>> 17be2de402..ce125f549f 100644 >>> --- a/app/test-pmd/cmdline.c >>> +++ b/app/test-pmd/cmdline.c >>> @@ -4133,6 +4133,7 @@ cmd_vlan_offload_parsed(void *parsed_result, >>> else >>> vlan_extend_set(port_id, on); >>> >>> + cmd_reconfig_device_queue(port_id, 1, 1); In addition, I have some comments: 1) Normally, the parsed function of testpmd command needed to re-config port and queue needs to check if port status is STOPED. Why don't you add this check? If the check is not exist, queue offloads are not updated until the next port stop/start command is executed. Right? 2) Why is the queue-based VLAN offload API not used?    Like, rte_eth_dev_set_vlan_strip_on_queue. It seems that this kind of API is    dedicated to do this. >> This means that queue offloads need to upadte by re-calling dev_configure >> and setup all queues, right? >> If it is, this adds a usage limitation. >>> return; >>> } >>>