From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 2112E239 for ; Tue, 26 Mar 2019 10:28:58 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 77DF5356E9; Tue, 26 Mar 2019 09:28:57 +0000 (UTC) Received: from [10.36.112.59] (ovpn-112-59.ams2.redhat.com [10.36.112.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B67BA5DAAD; Tue, 26 Mar 2019 09:28:56 +0000 (UTC) To: "Lu, Wenzhuo" , "dev@dpdk.org" References: <1551340136-83843-1-git-send-email-wenzhuo.lu@intel.com> <1553223516-118453-1-git-send-email-wenzhuo.lu@intel.com> <1553223516-118453-7-git-send-email-wenzhuo.lu@intel.com> <6A0DE07E22DDAD4C9103DF62FEBC0909407EFDD1@shsmsx102.ccr.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC0909407F0677@shsmsx102.ccr.corp.intel.com> From: Maxime Coquelin Message-ID: Date: Tue, 26 Mar 2019 10:28:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC0909407F0677@shsmsx102.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 26 Mar 2019 09:28:57 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v5 6/8] net/ice: support Rx AVX2 vector X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 09:28:58 -0000 Hi, On 3/26/19 2:00 AM, Lu, Wenzhuo wrote: > Hi Maxime, > >> -----Original Message----- >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >> Sent: Monday, March 25, 2019 4:26 PM >> To: Lu, Wenzhuo ; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v5 6/8] net/ice: support Rx AVX2 vector >> >> Hi, >> >> On 3/25/19 3:22 AM, Lu, Wenzhuo wrote: >>> Hi Maxime, >>> >>> >>>> -----Original Message----- >>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >>>> Sent: Friday, March 22, 2019 6:12 PM >>>> To: Lu, Wenzhuo ; dev@dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH v5 6/8] net/ice: support Rx AVX2 >>>> vector >>> >>> >>>>> +#ifndef RTE_LIBRTE_ICE_16BYTE_RX_DESC >>>> >>>> I see same is done for other Intel NICs, but I wonder what would be >>>> the performance cost of making it dynamic, if any cost? >>> Currently we don't have a good idea to make it dynamic. If we use pointer >> to point to different functions for 16 byte and 32 byte, there's too much >> duplicate code to make it hard to maintain. If we use the same function, and >> check the configure in it. It impacts the performance. >> >> Have you done some measurements, what would be the performance >> impact? > I mean if we check the configuration is 16 byte or 32 byte, this check will consume extra CPU cycles. > That why I think the better way is to have different paths for 16 byte and 32 byte. We should choose the appropriate path at the beginning. > >> >>> As HW does not support to change the configuration dynamically. The >> device must be stopped and restarted if the configuration is changed. It's not >> very helpful to make it a dynamic configuration. We assume that the users >> can make their choice at the beginning and will not change it. >> >> The problem is that the user has to recompile to switch between the two >> configurations. And it may not be an option for the user if he uses dpdk >> packaged by a distribution, for example. >> >> Maybe I was not clear, but I don't mean to be able to switch mode while the >> port is started. I think it would be better to make it possible to switch mode >> at application startup time. > Yes, I understand the problem is the recompiling. But we think the users will not change it after they made decision. That's why's acceptable in previous drivers. The problem is that the user may not be able to change it, if he does not get DPDK from source but from a distribution like Debian, Ubuntu or Red Hat. In this case, it means the user has no choice than sticking to 32 bytes descriptors. > Agree it's better to remove all the compile configuration. Looks like that's what we're trying to do. We'd like to think about how to optimize it later. My suggestion would be a devarg, so that you can have a per-port policy (which is another advantage of doing so). > > >> >>> >>>> >>>> Having it dynamic (as a dev arg for instance) would make it possible >>>> to change the value when the user is using dpdk from a distro. It >>>> would also help testing coverage. >>>> >>>> Btw, how do you select this option with meson build system? >>> Not very familiar with meson. As I know, we can change the meson.build >> to add the configure. >>> >> >> Ok, then please try to do it, because the legacy build system is going to be >> deprecated. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D3CB5A05D3 for ; Tue, 26 Mar 2019 10:29:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2BC8F1150; Tue, 26 Mar 2019 10:29:00 +0100 (CET) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 2112E239 for ; Tue, 26 Mar 2019 10:28:58 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 77DF5356E9; Tue, 26 Mar 2019 09:28:57 +0000 (UTC) Received: from [10.36.112.59] (ovpn-112-59.ams2.redhat.com [10.36.112.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B67BA5DAAD; Tue, 26 Mar 2019 09:28:56 +0000 (UTC) To: "Lu, Wenzhuo" , "dev@dpdk.org" References: <1551340136-83843-1-git-send-email-wenzhuo.lu@intel.com> <1553223516-118453-1-git-send-email-wenzhuo.lu@intel.com> <1553223516-118453-7-git-send-email-wenzhuo.lu@intel.com> <6A0DE07E22DDAD4C9103DF62FEBC0909407EFDD1@shsmsx102.ccr.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC0909407F0677@shsmsx102.ccr.corp.intel.com> From: Maxime Coquelin Message-ID: Date: Tue, 26 Mar 2019 10:28:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC0909407F0677@shsmsx102.ccr.corp.intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 26 Mar 2019 09:28:57 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v5 6/8] net/ice: support Rx AVX2 vector X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190326092854.1lWVz5ydwdCl9v5_giuO9nrbERd7gokKMq1eEN_ITmI@z> Hi, On 3/26/19 2:00 AM, Lu, Wenzhuo wrote: > Hi Maxime, > >> -----Original Message----- >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >> Sent: Monday, March 25, 2019 4:26 PM >> To: Lu, Wenzhuo ; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v5 6/8] net/ice: support Rx AVX2 vector >> >> Hi, >> >> On 3/25/19 3:22 AM, Lu, Wenzhuo wrote: >>> Hi Maxime, >>> >>> >>>> -----Original Message----- >>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >>>> Sent: Friday, March 22, 2019 6:12 PM >>>> To: Lu, Wenzhuo ; dev@dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH v5 6/8] net/ice: support Rx AVX2 >>>> vector >>> >>> >>>>> +#ifndef RTE_LIBRTE_ICE_16BYTE_RX_DESC >>>> >>>> I see same is done for other Intel NICs, but I wonder what would be >>>> the performance cost of making it dynamic, if any cost? >>> Currently we don't have a good idea to make it dynamic. If we use pointer >> to point to different functions for 16 byte and 32 byte, there's too much >> duplicate code to make it hard to maintain. If we use the same function, and >> check the configure in it. It impacts the performance. >> >> Have you done some measurements, what would be the performance >> impact? > I mean if we check the configuration is 16 byte or 32 byte, this check will consume extra CPU cycles. > That why I think the better way is to have different paths for 16 byte and 32 byte. We should choose the appropriate path at the beginning. > >> >>> As HW does not support to change the configuration dynamically. The >> device must be stopped and restarted if the configuration is changed. It's not >> very helpful to make it a dynamic configuration. We assume that the users >> can make their choice at the beginning and will not change it. >> >> The problem is that the user has to recompile to switch between the two >> configurations. And it may not be an option for the user if he uses dpdk >> packaged by a distribution, for example. >> >> Maybe I was not clear, but I don't mean to be able to switch mode while the >> port is started. I think it would be better to make it possible to switch mode >> at application startup time. > Yes, I understand the problem is the recompiling. But we think the users will not change it after they made decision. That's why's acceptable in previous drivers. The problem is that the user may not be able to change it, if he does not get DPDK from source but from a distribution like Debian, Ubuntu or Red Hat. In this case, it means the user has no choice than sticking to 32 bytes descriptors. > Agree it's better to remove all the compile configuration. Looks like that's what we're trying to do. We'd like to think about how to optimize it later. My suggestion would be a devarg, so that you can have a per-port policy (which is another advantage of doing so). > > >> >>> >>>> >>>> Having it dynamic (as a dev arg for instance) would make it possible >>>> to change the value when the user is using dpdk from a distro. It >>>> would also help testing coverage. >>>> >>>> Btw, how do you select this option with meson build system? >>> Not very familiar with meson. As I know, we can change the meson.build >> to add the configure. >>> >> >> Ok, then please try to do it, because the legacy build system is going to be >> deprecated.