From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by dpdk.org (Postfix) with ESMTP id 9A9548E69 for ; Wed, 13 Jan 2016 17:28:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2493; q=dns/txt; s=iport; t=1452702516; x=1453912116; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Wa79PD460sYf5qLzTzefXbWHh2qEiAqT4ejYdz84EUk=; b=F9YSs8onhFmZ74g+yZth7d2gcjzl0X7n+aAihF1TowF53SLRtBUA38wg erXIBgkHhUpQ4zj3qWONDnMkIT6JjWWXtjffuNUgm631P2dxneVYbjJWu bpcByi/QE7/2zUPK9Tlio5RpJyHQQXVjochUvmR/0f+8gLz4Nb0PtBBoV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgCuepZW/4wNJK1egzqBPwaIVLEAg?= =?us-ascii?q?hMBDYFkhg8CgTs4FAEBAQEBAQGBCoQ0AQEBBDo/DAQCAQgRBAEBAR4JBzIUCQg?= =?us-ascii?q?CBA4FCIgmwFMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlaDe4EEiT0FlxUBjVKBZ?= =?us-ascii?q?Y0iRIofg3IBIAEBQoQKcoUUAYEHAQEB?= X-IronPort-AV: E=Sophos;i="5.22,290,1449532800"; d="scan'208";a="225199117" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jan 2016 16:28:35 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0DGSZeV002306 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 16:28:35 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Jan 2016 11:28:34 -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; Wed, 13 Jan 2016 11:28:34 -0500 From: "Hanoch Haim (hhaim)" To: Bruce Richardson Thread-Topic: [dpdk-dev] [PATCH v2] mbuf: optimize rte_mbuf_refcnt_update Thread-Index: AQHRRvdSBdlb5jcirkKWcHjQnHrDiJ7ragvggAGrnoD//61g8IAM83IA///12zA= Date: Wed, 13 Jan 2016 16:28:34 +0000 Message-ID: <6d8a8e02397b4a01940064eaa1ceb581@XCH-RTP-017.cisco.com> References: <568A7959.7030506@6wind.com> <7f5255b98dcb4f2396ada16d5eb43e5a@XCH-RTP-017.cisco.com> <568BA1A1.2070300@6wind.com> <521c3b8c6a014c24824bb1c5f17dca03@XCH-RTP-017.cisco.com> <20160113114820.GB7216@bricha3-MOBL3> In-Reply-To: <20160113114820.GB7216@bricha3-MOBL3> 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] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , "Itay Marom \(imarom\)" , "Ido Barnea \(ibarnea\)" 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: Wed, 13 Jan 2016 16:28:37 -0000 Hi Bruce.=20 This is exactly what was possible before the patch and does *not* work afte= r this patch.=20 I think it is more related to the semantic of the API. My understanding of = the API was that I could allocate a share mbuf (ref=3D1) and then attach it= from many concurrent threads (as each thread attach opt inc in 1 and drive= r reduces, atomic by 1) After the patch there is a need to make the ref of the share mbuf to be 2 (= why?) and free it twice at the end( ?), this makes it cumbersome to use it = and for sure there is a need to describe this semantic change. However, this change is good for the common case, and I think it is better = to keep it. The options I see are: 1) Document the current behavior=20 2) Create two sets of API with two types of semantic=20 thanks, Hanoh -----Original Message----- From: Bruce Richardson [mailto:bruce.richardson@intel.com]=20 Sent: Wednesday, January 13, 2016 1:48 PM To: Hanoch Haim (hhaim) Cc: Olivier MATZ; dev@dpdk.org; Ido Barnea (ibarnea); Itay Marom (imarom) Subject: Re: [dpdk-dev] [PATCH v2] mbuf: optimize rte_mbuf_refcnt_update On Tue, Jan 05, 2016 at 11:11:24AM +0000, Hanoch Haim (hhaim) wrote: > Hi Oliver, > Thank you for the fast response and it would be great to open a discussio= n on that. > In general our project can leverage your optimization and I think it is g= reat (we should have thought about it) . We can use it using the workaround= I described. > However, for me it seems odd that rte_pktmbuf_attach () that does not *= change* anything in m_const, except of the *atomic* ref counter does not wo= rk in parallel. > The example I gave is a classic use case of rte_pktmbuf_attach (multicas= t ) and I don't see why it wouldn't work after your optimization.=20 >=20 > Do you have a pointer to the documentation that state that that you can't= call the atomic ref counter from more than one thread? >=20 Hi, actually, the issue is not that you can't work with the reference counter f= ield from multiple threads, or that you can't use an mbuf from multiple thr= eads, it's that if you are working with the same mbuf in multiple threads y= ou have multiple references to the mbuf and your application must increase = the reference counter appropriately. For example, if thread A is going to p= ass an mbuf to thread B and keep using it itself, you must increment the re= ference counter in thread A before enqueuing it to B. Regards, /Bruce