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 8CE56A051A; Thu, 16 Jan 2020 22:38:41 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CF82F1D51E; Thu, 16 Jan 2020 22:38:40 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 254FC1D511 for ; Thu, 16 Jan 2020 22:38:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579210719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DUqcwW4jGEZ9mdq875o3fIkwyodK8fmLmeW/r1xxZYo=; b=AiyOpDX08yUU/PMFQfnTSQk0eWD8pjotQqxfQlaE5oQDoKWLFGBjL72KL0Ec2sEPm/805y LQQUFm2iik0VyEKk+5lfJxJ3ztUDkoCsrcZBPeYyGYBITq2r6ejJRaGPn0z8QjCqPQtJlq ec+gNMXZCyIdtC+2y2W22rNdHMnvG+0= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-383-CNpZ-WJ1MraDoo4EIC_hgg-1; Thu, 16 Jan 2020 16:38:38 -0500 Received: by mail-vk1-f197.google.com with SMTP id 128so8788234vka.12 for ; Thu, 16 Jan 2020 13:38:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lQn7ihLUmh41B31PktHtFJRIC9T540mkxNxElc/Q3Zw=; b=DVmQTqqZa8rfgRNUBVsL4g00H6YupqqCBK4G96p/TnM3zoZapRiRDv6amasJnZ4U5u YKouUV2H4HR0fdNtf9zPMDgvRiObB1FUVWLyuw0r+uH8PdgRTBVXhQE0CFj+FbV+L6d9 M3J6aITzgVy+S2NfEBZutyDzUC94vY/c1fwkM31sNOp4cQqfSWmY/qLKl2QtlMxVekDx ex2p/NNcfk3OKtpA8EyOR/c+bnpulqIWEIvhaRIzSIVIFdtwSO3N9cZNCX2JLpnY2uzo n+TNMfGeQzwHY5fE52znsn5OcTz7zZ7MAf5gDXH3VfUY1OY/53Rv+R1X1goK1zLrPtVq /IbQ== X-Gm-Message-State: APjAAAWqv8j+zOxNx8b6wdimCCD8odFxvBYmnKRDamEExwQuX11C/u0i CwvvOTYqaDvCoYOCyP7y1n8ozlfrbNcRg1qjkGWtznqXRYJvf5OhgmVAHFAo5iuvHsyZvwNu2Ky neApibByDnIh6c+X7tTk= X-Received: by 2002:a05:6102:20ca:: with SMTP id i10mr3019570vsr.105.1579210717395; Thu, 16 Jan 2020 13:38:37 -0800 (PST) X-Google-Smtp-Source: APXvYqzFQ8Rxt0xKg7moVxlRxktwOHjdpieudzEPLye2mRRUUqmD6sllO30s5v2YOvC2mOoByU8bf1lFblmiSPU04vQ= X-Received: by 2002:a05:6102:20ca:: with SMTP id i10mr3019544vsr.105.1579210716938; Thu, 16 Jan 2020 13:38:36 -0800 (PST) MIME-Version: 1.0 References: <1561911676-37718-1-git-send-email-gavin.hu@arm.com> <1573162528-16230-3-git-send-email-david.marchand@redhat.com> <2601191342CEEE43887BDE71AB97725801A8C833FA@IRSMSX104.ger.corp.intel.com> <1931245.p08n36Xx7L@xps> <2601191342CEEE43887BDE71AB97725801A8C83A2B@IRSMSX104.ger.corp.intel.com> In-Reply-To: From: David Marchand Date: Thu, 16 Jan 2020 22:38:25 +0100 Message-ID: To: Honnappa Nagarahalli Cc: "Gavin Hu (Arm Technology China)" , Jerin Jacob , "Ananyev, Konstantin" , "thomas@monjalon.net" , "dev@dpdk.org" , "Mcnamara, John" , "Kovacevic, Marko" , "jerinj@marvell.com" , Jan Viktorin , nd X-MC-Unique: CNpZ-WJ1MraDoo4EIC_hgg-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v13 2/5] eal: add the APIs to wait until equal 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, Dec 10, 2019 at 8:52 AM Honnappa Nagarahalli wrote: > > > > > > Again I suppose they might be re-used in future some other ARM > > > specific low-level primitvies. > > > > > > > > > > Do this low-level routines _LOAD_EXC_ need to be exposed in EAL > > > > > for re- > > > use? > > > > > > > > About load_exc don't know for sure... > > > > Though as I can see wfe/sevl are used here: > > > > http://patchwork.dpdk.org/patch/61779/ > > > > Might be it is possible to reuse these functions/macros... > > > > But again, I am not arm expert, would be interested to know what ar= m > > > guys think. > > > > > > > > > Considering WFE has a requirement on using load_exec on ARM so IMO, i= t > > > makes sense to expose load_exec in conjunction with wfe/sevl to use i= t > > > properly. > > Agree, WFE should have more use cases can be developed, not limited to = the > > WAIT_UNTIL_EQUAL_XX APIs. Marvel's patch is an example. > > Sorry I don't have more use case so far, but Arm is evolving WFE, so I = think > > more use cases are emerging. > > /Gavin > I think the focus of this patch is 'rte_wait_until_equal_xxx' APIs. I wou= ld say, this patch serves that purpose as we all agree on the definition of= the APIs. > The implementation of the API may be conservative, but I think it is alri= ght as it does not bind us from changing it in the future. We can look at f= urther use cases as and when they come. Sorry for being so long to work on this. We discussed this in december with Honnappa. The main point that transpired is that there is no other usecase for wfe/sevl/loadex block than the rte_wait_until_equal APIs. I then intend to stick to the last version I sent, which only exposes these APIs and hides all the other details. If we need to expose those blocks for new usecases, then we will rediscuss the APIs. I will merge this series tomorrow so that it makes it into 20.02-rc1. If there are strong oppositions to my last changes, we can have followup patches on the implementation, the exposed APIs will be the same anyway. Thanks. --=20 David Marchand