From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by dpdk.org (Postfix) with ESMTP id 666B85A49 for ; Sun, 27 Dec 2015 10:39:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11913; q=dns/txt; s=iport; t=1451209170; x=1452418770; h=from:to:cc:subject:date:message-id:mime-version; bh=8W7YHGZ8BMKPeEwBenYF2ldfqTPjeOVb5HvCZmz0vMg=; b=S6rHLTsZhADLT2a0hFNOSdyC/wP/TXJj2UZn4dbcnzl7PuqrQvaooIRa eD3EvV4QXyE9lZiVLMavHUimkxGHtwdHGv072Ovj1GnOMnUcD/Vh5TntE xjKNQWIuWbE5Pd7VEKCL8wxdh++wmCcg08T4+6/yzVBQrEynXWgIG7RMS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgAIsX9W/4ENJK1egm5MUm0GiFO0Y?= =?us-ascii?q?QENgWUYAQmFbYEROBQBAQEBAQEBfwuENQEBAwEBAQEkBkwFDQEIFFkLJgEEDgU?= =?us-ascii?q?IiB8IDrkDAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZWhH+ERzAehCgFh16PKAGFP?= =?us-ascii?q?4gKgWNKjFVEigODcwEgAQFChAtyg2hBAYEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,485,1444694400"; d="scan'208,217";a="221147826" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Dec 2015 09:39:29 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tBR9dS2X024241 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 09:39:29 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 27 Dec 2015 04:39:27 -0500 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Sun, 27 Dec 2015 04:39:27 -0500 From: "Hanoch Haim (hhaim)" To: "bruce.richardson@intel.com" Thread-Topic: Re: [dpdk-dev] [PATCH v2] mbuf: optimize rte_mbuf_refcnt_update Thread-Index: AdFAini2Iq7ZWG4OR2ur+JVAZn8bww== Date: Sun, 27 Dec 2015 09:39:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.103.60.135] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" , "Hanoch Haim \(hhaim\)" , "Ido Barnea \(ibarnea\)" , "Itay Marom \(imarom\)" Subject: Re: [dpdk-dev] [PATCH v2] mbuf: optimize rte_mbuf_refcnt_update 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: Sun, 27 Dec 2015 09:39:31 -0000 Hi Bruce, I'm Hanoch from Cisco Systems works for the https://github.com/cisco-syste= m-traffic-generator/trex-core traffic generator project. While upgrading from DPDK 1.8 to 2.2 Ido found that the following commit cr= eates a mbuf corruption and result in Tx hang commit f20b50b946da9070d21e392e4dbc7d9f68bc983e Author: Olivier Matz Date: Mon Jun 8 16:57:22 2015 +0200 Looking at the change it is clear why there is an issue, wanted to get your= input. Init ----- alloc const mbuf =3D=3D> mbuf-a (ref=3D1) Simple case that works --------------------- thread 1 , tx: alloc-mbuf->attach(mbuf-a) (ref=3D2) inc- non atomic thread 1 , tx: alloc-mbuf->attach(mbuf-a) (ref32) inc- atomic thread 1 , drv : free() (ref=3D2) dec- atomic thread 1 , drv : free() (ref=3D3) dec - non atomic Simple case that does not work --------------------- Both do that in parallel thread 2 tx : alloc-mbuf->attach(mbuf-a) (ref=3D2) inc- non atomic thread 1 tx : alloc-mbuf->attach(mbuf-a) (ref=3D2) inc- non atomic =3D=3D> ref in corrupted thread 1 drv : free() (ref=3D0) - free thread 1 drv : free() (ref=3D-1) - ??? Just as a side note that in our case we could benefit from this optimizatio= n by making a small change in our code, as our common case could be alloc/f= ree of simple mbuf and in such scenario there is no atomic operation in bot= h cases. But I think the general case is broken. Could you explain what was your use case or this optimization? Is it a vali= d example the aforementioned example thanks, Hanoh Cisco Systems On Mon, Jun 08, 2015 at 04:57:22PM +0200, Olivier Matz wrote: > In __rte_pktmbuf_prefree_seg(), there was an optimization to avoid using > a costly atomic operation when updating the mbuf reference counter if > its value is 1. Indeed, it means that we are the only owner of the mbuf, > and therefore nobody can change it at the same time. > > We can generalize this optimization directly in rte_mbuf_refcnt_update() > so the other callers of this function, like rte_pktmbuf_attach(), can > also take advantage of this optimization. > > Signed-off-by: Olivier Matz > Acked-by: Bruce Richardson > Hanoh