From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Hanoch Haim (hhaim)" Subject: Re: [PATCH v2] mbuf: optimize rte_mbuf_refcnt_update 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Itay Marom \(imarom\)" , "Ido Barnea \(ibarnea\)" To: Bruce Richardson 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) In-Reply-To: <20160113114820.GB7216@bricha3-MOBL3> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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