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 C0038A04F3; Fri, 3 Jan 2020 08:34:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 186BB1C299; Fri, 3 Jan 2020 08:34:55 +0100 (CET) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 1797F1C246 for ; Fri, 3 Jan 2020 08:34:53 +0100 (CET) Received: by mail-il1-f195.google.com with SMTP id t8so35995373iln.4 for ; Thu, 02 Jan 2020 23:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DoypPPtphdAc+nAuybT4py7PRCKCCCH8BUjOsuEbB3c=; b=UUVdZ43keOWLDUbWQ99EW0npL4J27b17eCqZ2SlYbDLsL2tfVKyMcivyMNa8FHBcSC xHzcxCQsghm5nK27RiPslhkxtuaGBZcLmsUpdT5XrHBQNKnZopkFdDa4sKX60unVJU4e uxhmkEsbEog0+dkpBWMM5pYgGdh4wDkBxZKW7UGdMzOECcC3HD5tQEqz+1yYxaSdmpEF 1yBMZhB9rrCdW0hkT0cFRqhhMR8PW0FnYAgRpD8lD8NpmwZRuBJotsoCVQBpwDOIDQsX eBTu3JSFsAQyYjlv8SytnTtpy4ZJVMzl8cP0o7P8JKGi/rIE4y/9ZJthrkWPMXM/jFxQ ZAhQ== 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=DoypPPtphdAc+nAuybT4py7PRCKCCCH8BUjOsuEbB3c=; b=kO5BV8qHVxWvO3B1fgdwv0E6UxdEZrkeNziFGBRvQVgU1uWPGK8LtVypgCRSWebo2R +RkzrZPIqFyyKzHXILizKXO761Onbg+HacXetkr3qQ+4KXwfw7TAeU6wA5YBb+ovJHeb 9PwaH7cLmpTQwsz9KsCfQCkaJWR/upmxO9y1o0NcwW/UI/TFlNUpmOXSaYXwtYmXHVBj rAdsCU7kkCFISNHrTV0VbnrjwAX8VVP92XF3pfibFHuLarOrHbpi1CWCzoRJqwV+3YQv G0f2kU3OGTJ1nl/BmAPQO06kMcpJKXpYpbkT3G/8KPF73mL7adoHdgX5Yb7adwJpGv1y n75g== X-Gm-Message-State: APjAAAVckSoYpF5zJP4xuvTYjJwpcprcxH+pr9dfyKZz4Hl4dRzXD6Dx b5jN8b29yIrA5IF3taQ4oiuDLOfH45MXkpO4B4Y= X-Google-Smtp-Source: APXvYqwXlwbaDTBLhDCLMWzocw48EpDm1uKgSiJevUZ7iqMX4YizijEfkZzpPDKjThLQDAtEilvDkA1mhrqkUbBmtb4= X-Received: by 2002:a92:5e46:: with SMTP id s67mr75246068ilb.162.1578036892263; Thu, 02 Jan 2020 23:34:52 -0800 (PST) MIME-Version: 1.0 References: <1571758074-16445-1-git-send-email-gavin.hu@arm.com> <1576811391-19131-1-git-send-email-gavin.hu@arm.com> <1576811391-19131-2-git-send-email-gavin.hu@arm.com> In-Reply-To: From: Jerin Jacob Date: Fri, 3 Jan 2020 13:04:36 +0530 Message-ID: To: Gavin Hu Cc: dpdk-dev , nd , David Marchand , "thomas@monjalon.net" , "rasland@mellanox.com" , "maxime.coquelin@redhat.com" , "tiwei.bie@intel.com" , "hemant.agrawal@nxp.com" , "jerinj@marvell.com" , Pavan Nikhilesh , Honnappa Nagarahalli , Ruifeng Wang , Phil Yang , Joyce Kong , Steve Capper Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier for aarch64 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 Fri, Jan 3, 2020 at 12:00 PM Gavin Hu wrote: > > Hi Jerin, Hi Gavin, > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Thursday, January 2, 2020 5:52 PM > > To: Gavin Hu > > Cc: dpdk-dev ; nd ; David Marchand > > ; thomas@monjalon.net; > > rasland@mellanox.com; maxime.coquelin@redhat.com; tiwei.bie@intel.com; > > hemant.agrawal@nxp.com; jerinj@marvell.com; Pavan Nikhilesh > > ; Honnappa Nagarahalli > > ; Ruifeng Wang > > ; Phil Yang ; Joyce Kong > > ; Steve Capper > > Subject: Re: [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier for > > aarch64 > > > > On Mon, Dec 23, 2019 at 3:46 PM Gavin Hu wrote: > > > > > > Hi Jerin, > > > > > > > -----Original Message----- > > > > From: Jerin Jacob > > > > Sent: Monday, December 23, 2019 5:20 PM > > > > To: Gavin Hu > > > > Cc: dpdk-dev ; nd ; David Marchand > > > > ; thomas@monjalon.net; > > > > rasland@mellanox.com; maxime.coquelin@redhat.com; > > > > tiwei.bie@intel.com; hemant.agrawal@nxp.com; jerinj@marvell.com; > > > > Pavan Nikhilesh ; Honnappa Nagarahalli > > > > ; Ruifeng Wang > > > > ; Phil Yang ; Joyce Kong > > > > ; Steve Capper > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/3] eal/arm64: relax the io barrier for > > > > aarch64 > > > > > > > > On Mon, Dec 23, 2019 at 2:44 PM Gavin Hu wrote: > > > > > > > > > > Hi Jerin, > > > > > > > > Hi Gavin, > > > > > > > > > > > > > > I think we are on the same page with regard to the problem, and the > > > > situations, thanks for illuminating the historical background of the two > > > > barriers. > > > > > About the solution, I added inline comments. > > > > > > It will be optimization only when if we are changing in the fast path. > > > > > > In the slow path, it does not matter. > > > > > > I think, the First step should be to use rte_cio_* wherever it is > > > > > > coherent memory used in _fast path_. I think, Almost every driver > > > > > > fixed that. > > > > > > > > > > > > I am not against this patch(changing the slow path to use rte_cio* > > > > > > from rte_io* and virtio changes associated with that). > > > > > > If you are taking that patch, pay attention to all the drivers in the > > > > > > tree which is using rte_io* for mixed access in slowpath. > > > > > I see 30+ drivers has calling rte_io* directly or indirectly through > > > > rte_write/read*. > > > > > It is hard for me to figure out all the mixed accesses in these drivers, and > > > > as you said, it makes no sense to change the _slow path_. > > > > > > > > > > How about we keep the old rte_io as is, and introduce 'fast path' version > > > > of rte_io for new code use? > > > > > Then in future, we may merge the two? > > > > > Another reason about this proposal is maybe there is rte_io calling in > > the > > > > fast path, but they are not mixed accesses and rte_cio is not suitable. > > > > > > > > Could you share more details about the case where fastpath + rte_io > > > > needed + rte_cio is not suitable? > > > > > > Here is an example for i40e, in the fast path, but only a pure io memory > > access. > > > > > https://code.dpdk.org/dpdk/v19.11/source/drivers/net/i40e/i40e_rxtx.c#L12 > > 08 > > > > Yes. That's a performance issue. > > > > It could be changed to following for the fix that works on x86, arm64 > > with existing infra. > > > > From: > > I40E_PCI_REG_WRITE() > > > > to: > > > > rte_cio_wmb() > > I40E_PCI_REG_WRITE_RELAXED() > Yes, this is correct, I will submit a new patch for this. > This is an example out of all the cases that I must fix before relaxing the rte_io barriers. > My plan is as follows, any comments are welcome! > 1. replace rte_*mb and rte_io_*mb with rte_cio_*mb where applicable in the fastpath, this is an optimization, as the barriers are relaxed. > 2. replace all the rte_io_*mb with rte_cio_*mb where applicable in the slowpath and control path > 3. until *all* the occurrences in the step 1 and 2 are done, then this path can be re-activated. > > Please advise if the above approach works from your viewpoint. I would prefer to have ONLY the step (1) and add a note for the same in https://doc.dpdk.org/guides/prog_guide/perf_opt_guidelines.html as documentation reference. > Maybe I will stop at step 1, step 2 and 3 are not necessary as they are not in the fastpath? Yup. > > > > > > > > > I wanted two variants of rte_io, because also x86 requires two as indicated > > here, one for no-WC and another for WC. > > > http://inbox.dpdk.org/dev/20191204151916.12607-1- > > xiaoyun.li@intel.com/T/#ea8bb1b4a378ab09baedbf95b4542bcb92f4a396f > > > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > > > > > > > But as the case in i40e, we must pay attention to where rte_cio was > > > > > > missing but rescued by old rte_io(but not by new rte_io). > > > > > > > > > > > > > >