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 D7339A0352; Sun, 3 Nov 2019 21:46:56 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 34DC71BE98; Sun, 3 Nov 2019 21:46:56 +0100 (CET) Received: from q2relay189.mxroute.com (q2relay189.mxroute.com [160.202.107.189]) by dpdk.org (Postfix) with ESMTP id 8AB7C1BE95 for ; Sun, 3 Nov 2019 21:46:54 +0100 (CET) Received: from filter003.mxroute.com [168.235.111.26] (Authenticated sender: mN4UYu2MZsgR) by q2relay189.mxroute.com (ZoneMTA) with ESMTPSA id 16e33053b67000f36a.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sun, 03 Nov 2019 20:46:51 +0000 X-Zone-Loop: bd72f10eb6a5c784679fcef13cec7630096cbf2b5337 X-Originating-IP: [168.235.111.26] Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter003.mxroute.com (Postfix) with ESMTPS id D21D26115B for ; Sun, 3 Nov 2019 20:46:48 +0000 (UTC) Received: from irdmzpr01-ext.ir.intel.com ([192.198.151.36]) by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1iRMZw-0008QA-6i for dev@dpdk.org; Sun, 03 Nov 2019 15:34:28 -0500 To: dev@dpdk.org References: <20191031171139.105110-1-haiyue.wang@intel.com> <20191031171139.105110-3-haiyue.wang@intel.com> <20693558.VL3dRorq05@xps> <56850BFA-ABD1-476D-9ED0-F599EBD6D1EE@cisco.com> From: Ray Kinsella Openpgp: preference=signencrypt Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: <6f7c8364-f693-d17e-fe06-03708ef7bdf2@ashroe.eu> Date: Sun, 3 Nov 2019 20:46:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <56850BFA-ABD1-476D-9ED0-F599EBD6D1EE@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information 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" On 02/11/2019 19:21, Damjan Marion (damarion) wrote: > > >> On 2 Nov 2019, at 09:38, Slava Ovsiienko wrote: >> >> Hi >>> -----Original Message----- >>> From: Liu, Yu Y >>> Sent: Saturday, November 2, 2019 8:56 >>> To: Wang, Haiyue ; Thomas Monjalon >>> >>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh >>> ; jerinjacobk@gmail.com; Ye, Xiaolong >>> ; Kinsella, Ray ; Sun, >>> Chenmin ; Slava Ovsiienko >>> ; Damjan Marion (damarion) >>> ; Liu, Yu Y >>> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode >>> information >>> >>> Add Damjan from FD.io for awareness... >>> >>> Hi Thomas, >>> >>> Long time no see. Sorry I use outlook which is not friendly to community >>> email. >>> >>>> Anyway I will propose to replace this API in the next release. >>> Will your plan be affected by API/ABI stable plan? >>> BTW, if you propose new change in next release, it will make DPDK >>> consumer(FD.io) to change again. >>> So even if it is not affected to the API/ABI stable plan, do we still have time >>> to get a solution for everyone in DPDK 19.11 with your >>> contribution/acceleration? >>> >>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate. >>> Please be rest assured it is not the case. >>> This request is just from one FD.io project internal bug " tx/rx burst function >>> is shown as nil" reported by Chenmin. >> >> Why just the presenting string with function name (possible with suffix) is not enough? >> I would like to see this API (strings approach) in mlx5 either, dropping the entire feature >> does not look nice, as for me. >> >> We could consider some requirements for the name suffices to distinguish whether >> function uses vector instructions and which ones if any. >> >>> My understanding is DPDK behavior was taken as bug for someone in FD.io >>> project and potentially will mislead other DPDK consumer. >> >> Why does FD.io code want to know which vector extension is used by burst routines? >> Is it going to share/preserve some resources (registers, etc.)? Is it robust ? >> Burst routines might not know whether vector extensions is used (they might call >> libraries, even rte_memcpy() can use vectors in implicit fashion). > > This is jut debug CLI print, it was added by me as a result of frustration of dealing constantly with > operational issues where people are reporting lower performance caused by DPDK deciding > for variety of reasons to switch from vector PMD to scalar one. +1 I stated much the same elsewhere in this thread. If your using DPDK in place of alternative, you are doing so for performance reasons. If your performance drops in half becauses of configuration, you sure as hell want to understand why! Today consuming applications get wildly different performance from DPDK based on configuration. For me that is a huge usability issue and we can't leave the end user scratching their heads wonder what is going on. You program to our API and well take care of that doesn't cut it. User in the field deal with real performance degradation and need information to solve problems. This empowers them, and they shouldn't need to break out gdb to make it happen. > >> >>> Haiyue is working with Chenmin to address the issue and with your support it >>> will be even better. >>> >>> Your support will be highly appreciated! >>> >>> Thanks & Regards, >>> Yu Liu >>> >>> -----Original Message----- >>> From: dev On Behalf Of Wang, Haiyue >>> Sent: Saturday, November 2, 2019 1:30 PM >>> To: Thomas Monjalon >>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh >>> ; jerinjacobk@gmail.com; Ye, Xiaolong >>> ; Kinsella, Ray ; Sun, >>> Chenmin ; Slava Ovsiienko >>> >>> Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting >>> burst mode information >>> >>>> -----Original Message----- >>>> From: Thomas Monjalon >>>> Sent: Saturday, November 2, 2019 06:46 >>>> To: Wang, Haiyue >>>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh >>>> ; jerinjacobk@gmail.com; Ye, Xiaolong >>>> ; Kinsella, Ray ; Sun, >>>> Chenmin ; Slava Ovsiienko >>>> >>>> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst >>>> mode information >>>> >>>> Thank you for trying to address comments done late. >>>> >>>> 31/10/2019 18:11, Haiyue Wang: >>>>> --- a/lib/librte_ethdev/rte_ethdev.h >>>>> +++ b/lib/librte_ethdev/rte_ethdev.h >>> >>> >>>>> +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2) >>>>> +#define RTE_ETH_BURST_NEON (1ULL << 3) >>>>> +#define RTE_ETH_BURST_SSE (1ULL << 4) >>>>> +#define RTE_ETH_BURST_AVX2 (1ULL << 5) >>>>> +#define RTE_ETH_BURST_AVX512 (1ULL << 6) >>>> >>>> Of course, I still believe that giving a special treatment to vector >>>> instructions is wrong. >>>> You did not justify why it needs to be defined in bits instead of >>>> string. I am not asking again because anyway you don't really reply. I >>>> think you are executing an order you received and I don't want to >>>> blame you more. >>>> I suspect a real hidden issue in Intel CPUs that you try to mitigate. >>>> No need to reply to this comment. >>>> Anyway I will propose to replace this API in the next release. >>> >>> Never mind, if this design is truly ugly, drop it all now. I also prefer to do the >>> best, that's why open source is amazing, thanks! ;-) >> > >