On Tue, 5 Nov 2019 15:12:07 +0000 Ferruh Yigit <ferruh.yi...@intel.com> wrote:
> On 11/3/2019 7:50 AM, Slava Ovsiienko wrote: > > > > > >> -----Original Message----- > >> From: Damjan Marion (damarion) <damar...@cisco.com> > >> Sent: Saturday, November 2, 2019 21:21 > >> To: Slava Ovsiienko <viachesl...@mellanox.com> > >> Cc: Liu, Yu Y <yu.y....@intel.com>; Wang, Haiyue <haiyue.w...@intel.com>; > >> Thomas Monjalon <tho...@monjalon.net>; dev@dpdk.org; > >> arybche...@solarflare.com; Yigit, Ferruh <ferruh.yi...@intel.com>; > >> jerinjac...@gmail.com; Ye, Xiaolong <xiaolong...@intel.com>; Ray Kinsella > >> <ray.kinse...@intel.com>; Sun, Chenmin <chenmin....@intel.com> > >> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode > >> information > >> > >> > >> > >>> On 2 Nov 2019, at 09:38, Slava Ovsiienko <viachesl...@mellanox.com> > >> wrote: > >>> > >>> Hi > >>>> -----Original Message----- > >>>> From: Liu, Yu Y <yu.y....@intel.com> > >>>> Sent: Saturday, November 2, 2019 8:56 > >>>> To: Wang, Haiyue <haiyue.w...@intel.com>; Thomas Monjalon > >>>> <tho...@monjalon.net> > >>>> Cc: dev@dpdk.org; arybche...@solarflare.com; Yigit, Ferruh > >>>> <ferruh.yi...@intel.com>; jerinjac...@gmail.com; Ye, Xiaolong > >>>> <xiaolong...@intel.com>; Kinsella, Ray <ray.kinse...@intel.com>; Sun, > >>>> Chenmin <chenmin....@intel.com>; Slava Ovsiienko > >>>> <viachesl...@mellanox.com>; Damjan Marion (damarion) > >>>> <damar...@cisco.com>; Liu, Yu Y <yu.y....@intel.com> > >>>> 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-52b5e8ec9...@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.
