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 4C6EAA04A2; Tue, 5 Nov 2019 16:54:53 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 84B571C020; Tue, 5 Nov 2019 16:54:52 +0100 (CET) Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by dpdk.org (Postfix) with ESMTP id 339921BEF9 for ; Tue, 5 Nov 2019 16:54:51 +0100 (CET) Received: by mail-pf1-f196.google.com with SMTP id p26so15805165pfq.8 for ; Tue, 05 Nov 2019 07:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=RzaORm9N93O5HVZKSJfGcThwBXeNd/lI2TpRK1PvZbw=; b=idS8QOY/O+0i4v6PEspBapZ/ITGw1brt+L2PlMJ80A4fjZ0w53D1sEOhJo0xUo0u7W Z9kBjQIyT9aPpxZhZM9Pb7D6+4s2O9yMjyIO8IhugLHUjp52a4XFLdP+txOiI4zUIxXL k+wYe2XlWJltLVaWeDGZiFD1+8QVQTqXkfcR46FepZh9iSEEKkTmV9uGbwWlvSh3SBwV uRJvBsoz7bmsR1iKVeSRUP2e7paI63e614x15IfkCbSNm6K+IHe7id3dqKvRirP0u/yD lG+yYh1gIzm+CFDtv/GNS9xaBlKtvy0tXqyAx4SOPgRon31+zaKumjF8kQ8mrMO57+Nh nQnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RzaORm9N93O5HVZKSJfGcThwBXeNd/lI2TpRK1PvZbw=; b=gI71wtfI7S4gZuIj4nXRuKquYCjFEqAGmtxmnqnER8vtI77lZizTwoexTLdgGVb9Dt 29zCBkgzducppX86fb2AzUHspTXw3yUbbdoRBRf9XpXulb1TJ8Su9X+Kagz53ps1KVM6 mLEQ8n4XOwHFKP2EE3IF2ODp0GNojG2svbm73rz+2zm1e8AR6m1uPuFrmzsaNT1pNkzU GLOIIbsiZJXQX+4LQtFaEMITZVGL/ftfII0ON//fg1/dGRZtqPzxwdAEN5QtJLMSEg2S Pz40LipjyGkoPBjX0JNBrdbg3VoiWYJX4rry93ugdjMmWsMfXf0efPjTTihOnHGElXes KwgA== X-Gm-Message-State: APjAAAWKnQh1JdJ3rdZSDACvT/ljrBAc8/d5u7T3RlPaZJn9os2G6HIV rPGMJExsG81+FYDfY3QDH5wC/w== X-Google-Smtp-Source: APXvYqxgSoz7WGZ4MEyAzTkw4BFLH2JwH5OPrIm1FL2IEuh8br9lJG5V6+jY5qPmetTGq2w0b5G04A== X-Received: by 2002:a17:90a:3522:: with SMTP id q31mr7675240pjb.18.1572969290349; Tue, 05 Nov 2019 07:54:50 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 6sm22466675pfy.43.2019.11.05.07.54.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Nov 2019 07:54:50 -0800 (PST) Date: Tue, 5 Nov 2019 07:54:45 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: Slava Ovsiienko , "Damjan Marion (damarion)" , "Liu, Yu Y" , "Wang, Haiyue" , Thomas Monjalon , "dev@dpdk.org" , "arybchenko@solarflare.com" , "jerinjacobk@gmail.com" , "Ye, Xiaolong" , Ray Kinsella , "Sun, Chenmin" Message-ID: <20191105075445.08b8c1ba@hermes.lan> In-Reply-To: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 5 Nov 2019 15:12:07 +0000 Ferruh Yigit wrote: > On 11/3/2019 7:50 AM, Slava Ovsiienko wrote: > > > > > >> -----Original Message----- > >> From: Damjan Marion (damarion) > >> Sent: Saturday, November 2, 2019 21:21 > >> To: Slava Ovsiienko > >> Cc: Liu, Yu Y ; Wang, Haiyue ; > >> Thomas Monjalon ; dev@dpdk.org; > >> arybchenko@solarflare.com; Yigit, Ferruh ; > >> jerinjacobk@gmail.com; Ye, Xiaolong ; Ray Kinsella > >> ; Sun, Chenmin > >> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode > >> information > >> > >> > >> > >>> 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. > > > > And it seems there is no need for flags, as for me. > > I think the simple string would be quite enough to identify the datapath routine. > > Also, we have exact the same issue with mlx5 PMD, so the API (in simple > > string version) is desirable (+1 from me). > > > > Hi Thomas, Slava, > > It has been discussed in the previous mail thread [1], there was no objection to > it and Haiyue seems send the version based on it. > > > For me having the flag still makes sense, because: > 1) It helps standardizing the provided string. > 2) Helps to the application to consume the provided data via API (not text) > > The idea was PMD sets the flag for the know standard features, provides the text > for the non standard part. > The APIs converts the flag to the string and append to text so it will be > complete for the app if just wants to log it. Flags still has the standard part > for the application what to use it. > Initially standard part was just vectorization but it can be extended by time as > more common data path used by PMDs. Text part is always free text. > > > After above said, I think the API has been already discussed more than enough, > and Haiyue already sent an all string version, OK to go with it. > > [1] > http://inbox.dpdk.org/dev/a6893929-f981-4701-7cce-52b5e8ec934e@intel.com/ The string gives more flexibility there is no reason that driver should not be free to offer any number of algorithms. Likewise, the application should not care which algorithm is used. The return value must be for information use only.