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 CCD19A0352; Mon, 23 Dec 2019 10:20:04 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7E0FF2BA3; Mon, 23 Dec 2019 10:20:04 +0100 (CET) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id CB944F72 for ; Mon, 23 Dec 2019 10:20:02 +0100 (CET) Received: by mail-il1-f196.google.com with SMTP id f10so13475478ils.8 for ; Mon, 23 Dec 2019 01:20:02 -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=6K+eMg6yE5QrG95eI3GLcq2r03qKsXMjBSj0/tzCYhY=; b=VDXDlTgSU3CaL6itjoJEgjw/GzPg30FqVBLf88xax1D4SMHmXieXiAeiXiKPLjcfT0 NnquiDB+OZoGt9Bn2wuxP3SF6BFRLvN5tnyCxeTthzKSystPmWI8iIFWQ0nMzxpkaGun EW2jQb8ycKF6IwinL9itDfkkon3CwbzIfGcW4tWusqyw4GFR14M60WHz8Q21foupqS6i c8c1nq072g4tRGGnsqNZApaNRD39GawlRRXinmOTeVAlb1EbIwNchQSRDpC9SGWAOz44 1fldkUlQ2XfJXenYgU0SSr3xLHXMpP6fgFguDSk7u2ACO9/p5NXmz3ArVIXBcNX2hG97 TFvA== 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=6K+eMg6yE5QrG95eI3GLcq2r03qKsXMjBSj0/tzCYhY=; b=a/BkjCdX9BZSNRxqfJNfmhMldEz6OdtWljm2Y6xXzhBUaLBt3ntv/odcW86+Nxspey BtQq+Ejaf4GRvv/+GhpZNIzwK39/x07ZnsTMURij3Fn5mjaWQRrwF9VPor0rRifsHr+6 ACk9oJl/zf1SgN9IgSYp5m9HehC6vlwrGn9Jqqq6dvvaTQzMGw49QQ5ZcWDTuzcoav1o YfTy72ngpLu+A9m/5/RuPJi4nG/ORFgFZ9CUx7goDfNe0XWLEOhDL9WoXPiUCp1gQWj9 gazxYK8uchU2tOin6qHHO4GuUq8bmXg/LlSKgMCbcHhej7iuF/cUR6F9TNLkuSYn8auI kRBA== X-Gm-Message-State: APjAAAXh6RBNlpL+Q58wpGAOW14bpVuxQ+1Xiahy8Sc/atoV2+RhKWhG OQsr8u/ALx2FAta3LsaauJGePgIte1GrFxA+2qg= X-Google-Smtp-Source: APXvYqwXT10qn9qvFhrt3M5/YRhnpQNf7mJ0NsWSov5pJ4W8MVXBfttDm3fM0GPTX6ouC0plLuuzpmc+S0SevJ9AAxk= X-Received: by 2002:a92:5e46:: with SMTP id s67mr24823312ilb.162.1577092802061; Mon, 23 Dec 2019 01:20:02 -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: Mon, 23 Dec 2019 14:49:45 +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 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? > > 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). > > > > > >