From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 5985A9256 for ; Tue, 5 Jan 2016 11:58:12 +0100 (CET) Received: by mail-wm0-f44.google.com with SMTP id u188so18382960wmu.1 for ; Tue, 05 Jan 2016 02:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZzgEttQrPf02uPV7UalCH2J3xHF5radEuy+p5YT5vAQ=; b=X1Zf6NhpyD0MihzbqEjrN1TlbfyO71Ne/N8xcs5MmDEqeL2F1kWpeBBtWvbilVb+Dt xcMkRs/+isJQQwL7Vqf+239/DCIkJ8Ija7A3sS5LMKwf5vLlqJkLIdfGt5K6eES+OgXp dIHOkDVWBUbKq436+o/3Z+920gJ11d5cY+nfrbW8jPAcyQ/tAWiKX1/SJCpb1KBi8RJp CSF33cSBFivRbIlkEoDkms/Pz7VxcN9oo2S8oRX7geOsk6pzv7J5uwiyZYL+uZ2XH8zQ pO9FDypHPgx5RzwfmOJEm1Ngb3yNswcp7QQNwWy+MOidxbu/RQ7OfQhy41Qam0mSLGVj 5XTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZzgEttQrPf02uPV7UalCH2J3xHF5radEuy+p5YT5vAQ=; b=ihsAuGhmZ0BpJNnuylOrrFpx9xjGTDU/y/wrtHgvKOkrFwtd+kcgyuC1O18hyss8+l vaOY2RcKlwzW14gLEJoRf/SBXI6Wukoz1jdcHKdkaM1cSPIEbXMLCzy4W+LJdio8NfPo NTDogBsRHCaK+vhEOcWoRuW5WdKOu+Ub4lobHdw1aS8upcM/rdwXiniMtRIsLUpmH3uB FecfD46cJRDMu9pcuIiDaVP6Z59SGFL5iPBvRNbReURjmrryE9muH66PccHc9ruBnWkL iyCqrItr2BOhuOfgoErLVj0skvxG0cxfqY4+xhk+UqgBv1eonTylCPqFljE5SIv7fLVi wP5w== X-Gm-Message-State: ALoCoQn4UMaciGsjzXUhiY51mTRKR0B0mT9msIii9ImVhxXCuUSu8du1s2WG5nf33vkAVh33UyyawmC7bm3c03j3jzecjonbow== X-Received: by 10.194.157.165 with SMTP id wn5mr78632765wjb.41.1451991492172; Tue, 05 Jan 2016 02:58:12 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id w23sm2966853wmd.1.2016.01.05.02.58.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jan 2016 02:58:09 -0800 (PST) Message-ID: <568BA1A1.2070300@6wind.com> Date: Tue, 05 Jan 2016 11:57:37 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: "Hanoch Haim (hhaim)" , "bruce.richardson@intel.com" References: <568A7959.7030506@6wind.com> <7f5255b98dcb4f2396ada16d5eb43e5a@XCH-RTP-017.cisco.com> In-Reply-To: <7f5255b98dcb4f2396ada16d5eb43e5a@XCH-RTP-017.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , "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: Tue, 05 Jan 2016 10:58:12 -0000 Hi Hanoch, On 01/04/2016 03:43 PM, Hanoch Haim (hhaim) wrote: > Hi Oliver, > > Let's take your drawing as a reference and add my question > The use case is sending a duplicate multicast packet by many threads. > I can split it to x threads to do the job and with atomic-ref (my multicast not mbuf) count it until it reaches zero. > > In my following example the two cores (0 and 1) sending the indirect m1/m2 do alloc/attach/send > > core0 | core1 > --------------------------------- |--------------------------------------- > m_const=rte_pktmbuf_alloc(mp) | > | > while true: | while True: > m1 =rte_pktmbuf_alloc(mp_64) | m2 =rte_pktmbuf_alloc(mp_64) > rte_pktmbuf_attach(m1, m_const) | rte_pktmbuf_attach(m1, m_const) > tx_burst(m1) | tx_burst(m2) > > Is this example is not valid? For me, m_const is not expected to be used concurrently on several cores. By "used", I mean calling a function that modifies the mbuf, which is the case for rte_pktmbuf_attach(). > BTW this is our workaround > > > core0 | core1 > --------------------------------- |--------------------------------------- > m_const=rte_pktmbuf_alloc(mp) | > rte_mbuf_refcnt_update(m_const,1)| <<-- workaround > | > while true: | while True: > m1 =rte_pktmbuf_alloc(mp_64) | m2 =rte_pktmbuf_alloc(mp_64) > rte_pktmbuf_attach(m1, m_const) | rte_pktmbuf_attach(m1, m_const) > tx_burst(m1) | tx_burst(m2) This workaround indeed solves the issue. Another solution would be to protect the call to attach() with a lock, or call all the rte_pktmbuf_attach() on the same core. I'm open to discuss this behavior for rte_pktmbuf_attach() function (should concurrent calls be allowed or not). In any case, we may want to better document it in the doxygen API comments. Regards, Olivier