From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f194.google.com (mail-yb0-f194.google.com [209.85.213.194]) by dpdk.org (Postfix) with ESMTP id DD18B2931 for ; Fri, 2 Sep 2016 18:31:50 +0200 (CEST) Received: by mail-yb0-f194.google.com with SMTP id f60so2517343ybi.3 for ; Fri, 02 Sep 2016 09:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=2dQjSfn9Ovm3D9SR+2BSqhLE16GULdAyukvCAzzy+T0=; b=D5JdlEi30SOF3jPH1vm28+zIUcOfOik2K3rDzaOjWYBG9LQBVIre0Js28fwmAPSSVB Bx2nkWukIfGt6A2RcHtFFQQZWsVaIoeSD+uOVoJJjqtto9Mm8B2UTKmKMvKXmdmkrHZY luqHy1mnRj9Rum+dK6G/9n+qoevJzjDAmDgqHNA0LkPgwXJaiS1D9kkzw003tNBCYV7P GkKXTpzg7BQZtedEn+VWCf+ZDLXs0JR5/rFDws1n5YB3mUDDNP0OFplaFiA58c4/r0eA UFjNQj7fbSHL1I/I+2cY6Fw+BiUUnWqQfwwohjdKSI38Q4O+Vic8IJvDFZanCQtUKQx9 nZpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=2dQjSfn9Ovm3D9SR+2BSqhLE16GULdAyukvCAzzy+T0=; b=hD9UeXYmp3EHLr9GM+cNFgOOhGW3N8Ge1Lwaw6dsoobbfVqmRiVYfGhtja32Xnpf95 pYxOMSF1xIWYevIbmvJ9Ncyk58kiJA8ds4OdAa9TCtK+yvyDpAQR3CVlXK5TbMgjCbuA l4qbnjHhHRRT/Y95RIjPjfnQz155/N20cC9+F8HDMj4UH/1UxkqFHnBS7TKlEXlNNCdF bAC2M9FcjgMsjnqumNiMMbx261sU0aGQOm/qiHeyU7Z8EfzwRM+zhABWSO94Q20jxlvr RFhFwjd+PEzeSZF7HMuGSApT94B3HPMu4kKSEBpcMdQZLi55v19b0BDoUocy9KnBv1Hd BMPQ== X-Gm-Message-State: AE9vXwP5QIp9Il6tgR7DpPGvt0Jm27YFVs82vvrfchfIFfUi5OxHfRrz3GZzxCmkFC1X88QKSB4JHThnWJT9Gg== X-Received: by 10.37.51.132 with SMTP id z126mr18030947ybz.2.1472833910393; Fri, 02 Sep 2016 09:31:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.240.71 with HTTP; Fri, 2 Sep 2016 09:31:50 -0700 (PDT) In-Reply-To: <20160902091236.57250d1a@xeon-e3> References: <1472793906-5699-1-git-send-email-slayercat.subscription@gmail.com> <20160902091236.57250d1a@xeon-e3> From: Linzhe Lee Date: Sat, 3 Sep 2016 00:31:50 +0800 Message-ID: To: Stephen Hemminger , dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] mbuf: fix atomic refcnt update synchronization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 16:31:51 -0000 Thanks for reply, Stephen. I'm in x86-64, my cpu is `Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz`. When allocation mbuf in program1, and transfer it to program2 for free via ring, the program1 might meet assert in allocate mbuf sometimes. (`RTE_ASSERT(rte_mbuf_refcnt_read(m) =3D=3D 0);`) but when I using gdb to check it, the refcnt field of mbuf is already zero. so I believe the problem came from the cache line problem or incorrect optimization. When apply this patch, the problem seems solved. I'm submitting it for your comments. 2016-09-03 0:12 GMT+08:00 Stephen Hemminger : > On Fri, 2 Sep 2016 13:25:06 +0800 > lilinzhe wrote: > >> From: =E6=9D=8E=E6=9E=97=E5=93=B2 >> >> chagne atomic ref update to always call atomic_add >> >> when mbuf is allocated by cpu1 and freed by cpu2. cpu1 cache may not be = updated by such a set operation. >> causes refcnt reads incorrect values. > > What architecture are you dealing with? On X86 memory is cache coherent. > > Doing atomic operation all the time on each mbuf free would significantly > slow down performance. >