From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cmailsend26.nm.naver.com (cmailsend26.nm.naver.com [125.209.239.203]) by dpdk.org (Postfix) with ESMTP id 5B52511F5 for ; Wed, 7 Oct 2015 10:39:31 +0200 (CEST) Received: (qmail 17910 invoked by uid 100); 7 Oct 2015 08:39:29 -0000 Received: from 10.114.49.84 (HELO cweb17.nm.nhnsystem.com) (10.114.49.84) by cmailsend26.nm.naver.com with SMTP;7 Oct 2015 08:39:29 -0000 Date: Wed, 7 Oct 2015 17:39:28 +0900 (KST) From: =?UTF-8?B?7LWc7J217ISx?= To: dev@dpdk.org Message-ID: <99d046f3bd6cd566451bd5793eb669c@cweb17.nm.nhnsystem.com> MIME-Version: 1.0 Importance: normal X-Priority: 3 (Normal) X-Naver-CIP: 129.254.191.249 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] =?utf-8?q?_Can_the_dpdk_pktgen_check_the_sequence_of_r?= =?utf-8?q?eceived_packets=3F?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?UTF-8?B?7LWc7J217ISx?= List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 08:39:32 -0000 RGVhciBEUERLIGV4cGVydHMuCiAKVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBleGNlbGxl bnQgZWZmb3J0cyBhbmQgY29udHJpYnV0aW9ucy4KIApJIGFtIHN0dWR5aW5nIGRwZGsgcGt0Z2Vu LgogCkkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHNlcXVlbmNlIGNoZWNraW5nIGZvciByZWNlaXZl ZCBwYWNrZXRzIGluIHBrdGdlbi4KIApDYW4gdGhlIGRwZGsgcGt0Z2VuIGNoZWNrIHRoZSBzZXF1 ZW5jZSBvZiByZWNlaXZlZCBUQ1AgcGFja2V0cz8KIApJcyB0aGVyZSBhbnkgd2lzZSB3YXkgdG8g Y2hlY2sgdGhlIHNlcXVlbmNlIG9mIFVEUCBwYWNrZXRzPwogCklmIGl0IGlzIHBvc3NpYmxlLCB3 b3VsZCB5b3UgbGV0IG1lIGtub3cgaG93IGNhbiBJIHVzZSBpdD8KIApJIHdpbGwgcmVhbGx5IGFw cHJlY2lhdGUgZm9yIHlvdXIgcHJlY2lvdXMgYW5zd2VycyBhbmQgYWR2aWNlcy4KIApUaGFuayB5 b3UgdmVyeSBtdWNoLgogClNpbmNlcmVseSBZb3VycywKIApJY2stU3VuZyBDaG9pLgogCg== >From pnk003@naver.com Wed Oct 7 11:07:27 2015 Return-Path: Received: from cmailsend28.nm.naver.com (cmailsend28.nm.naver.com [125.209.239.205]) by dpdk.org (Postfix) with ESMTP id 6E6CC5961 for ; Wed, 7 Oct 2015 11:07:26 +0200 (CEST) Received: (qmail 7132 invoked by uid 100); 7 Oct 2015 09:07:24 -0000 Received: from 10.114.49.163 (HELO cweb01.nm.nhnsystem.com) (10.114.49.163) by cmailsend28.nm.naver.com with SMTP;7 Oct 2015 09:07:23 -0000 Date: Wed, 7 Oct 2015 18:07:23 +0900 (KST) From: =?UTF-8?B?7LWc7J217ISx?= To: dev@dpdk.org Message-ID: <47e2b06de73965fb579acd9170ae1f@cweb01.nm.nhnsystem.com> MIME-Version: 1.0 Importance: normal X-Priority: 3 (Normal) X-Naver-CIP: 129.254.191.249 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] =?utf-8?q?_Question_about_store=5Freturn=28=29_in_=7E/?= =?utf-8?q?dpdk/lib/librte=5Fdistributor/rte=5Fdistributor=2Ec?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?UTF-8?B?7LWc7J217ISx?= List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 09:07:27 -0000 RGVhciBEUERLIGV4cGVydHMuCiAKVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBleGNlbGxl bnQgZWZmb3J0cyBhbmQgY29udHJpYnV0aW9ucy4KIApJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBz dG9yZV9yZXR1cm4oKSBpbiB+L2RwZGsvbGliL2xpYnJ0ZV9kaXN0cmlidXRvci9ydGVfZGlzdHJp YnV0b3IuYwogClRoZSBzdG9yZV9yZXR1cm4oKSBmdW5jdGlvbiBhZGRzIGEgb2xkYnVmIHBhY2tl dCB0byBkLSZndDtyZXR1cm5zLm1idWZbXSBxdWV1ZS4KIApJZiB0aGUgcXVldWUgaXMgZnVsbCBh bmQgdGhlIG9sZGJ1ZiBwYWNrZXQgaXMgTlVMTCwgdGhlIHF1ZXVlIHNlZW1zIHRvIGxvc3QgYSBw YWNrZXQgaW4gdGhlIHF1ZXVlIHdpdGhvdXQgbW9kaWZ5aW5nIHJldF9zdGFydC9yZXRfY291bnQg dmFsdWVzLgogCklzIHRoZSBsYXN0IHBvc2l0aW9uIG9mIHRoZSBxdWV1ZSBhbHdheXMgZW1wdHk/ CiAKV291bGQgeW91IGNoZWNrIGl0PyAKIAogCiNkZWZpbmUgUlRFX0RJU1RSSUJfTUFYX1JFVFVS TlMgMTI4CiNkZWZpbmUgUlRFX0RJU1RSSUJfUkVUVVJOU19NQVNLIChSVEVfRElTVFJJQl9NQVhf UkVUVVJOUyAtIDEpCiAKLyogc3RvcmVzIGEgcGFja2V0IHJldHVybmVkIGZyb20gYSB3b3JrZXIg aW5zaWRlIHRoZSByZXR1cm5zIGFycmF5ICovCnN0YXRpYyBpbmxpbmUgdm9pZApzdG9yZV9yZXR1 cm4odWludHB0cl90IG9sZGJ1Ziwgc3RydWN0IHJ0ZV9kaXN0cmlidXRvciAqZCwKICAgICAgICAg ICAgICAgIHVuc2lnbmVkICpyZXRfc3RhcnQsIHVuc2lnbmVkICpyZXRfY291bnQpCnsKICAgICAg ICAvKiBzdG9yZSByZXR1cm5zIGluIGEgY2lyY3VsYXIgYnVmZmVyIC0gY29kZSBpcyBicmFuY2gt ZnJlZS4gYnVmZmVyIOuBneyXkCBvbGRidWbrpbwg7LaU6rCA7ZWoICovCiAgICAgICAgZC0mZ3Q7 cmV0dXJucy5tYnVmc1soKnJldF9zdGFydCArICpyZXRfY291bnQpICZhbXA7IFJURV9ESVNUUklC X1JFVFVSTlNfTUFTS10KICAgICAgICAgICAgICAgICAgICAgICAgPSAodm9pZCAqKW9sZGJ1ZjsK ICAgICAgICAqcmV0X3N0YXJ0ICs9ICgqcmV0X2NvdW50ID09IFJURV9ESVNUUklCX1JFVFVSTlNf TUFTSykgJmFtcDsgISEob2xkYnVmKTsKICAgICAgICAqcmV0X2NvdW50ICs9ICgqcmV0X2NvdW50 ICE9IFJURV9ESVNUUklCX1JFVFVSTlNfTUFTSykgJmFtcDsgISEob2xkYnVmKTsKfQogCklmIGQt Jmd0O3JldHVybnMubWJ1ZnNbXSBxdWV1ZSBpcyBmdWxsLCBvbGRidWYgcmVwbGFjZXMgdGhlIGZp cnN0IGNlbGwgb2YgdGhlIHF1ZXVlIChuZXcgcGFja2V0IG92ZXJ3cml0ZXMgdGhlIGxhc3QgcGFj a2V0IGluIHRoZSBxdWV1ZSkuCiAKcmV0X3N0YXJ0IGlzIHByZXNlcnZlZCBpZiB0aGUgcXVldWUg aXMgbm90IGZ1bGwgKGNvdW50IT0gTUFYX1ZBTFVFKFJURV9ESVNUUklCX1JFVFVSTlNfTUFTSykp CmlmIHJldF9zdGFydCBpcyBNQVggdmFsdWUgYW5kIG9sZGJ1ZiBpcyBub3QgTlVMTCwgcmV0X3N0 YXJ0IGlzIGluY3JlbWVudGVkIGJ5IDEuCiAKcmV0X2NvdW50IGlzIGluY3JlbWVudGVkIGJ5IDEg aWYgaXQgaXMgbm90IE1BWCB2YWx1ZSBhbmQgb2xkYnVmIGlzIG5vdCBOVUxMKS4KaWYgcmV0X2Nv dW50IGlzIE1BWCB2YWx1ZSwgcmV0X2NvdW50IGlzIHByZXNlcnZlZC4KIApUaGUgbWJ1ZnMgcXVl dWUgaXMgd3JpdHRlbiBieSBvbGRidWYoTlVMTCkgZXZlbiB0aG91Z2ggd2hlbiB0aGUgcXVldWUg aXMgZnVsbCBhbmQgdGhlIG9sZGJ1ZiBwYWNrZXQgaXMgTlVMTCAobm8gcGFja2V0IGluc2VydGlv bikuIApJdCBtYXkgbG9zdCBhIGNlbGwgaW4gdGhlIHF1ZXVlLgpJZiB0aGUgbGFzdCBwb3NpdGlv biBvZiB0aGUgcXVldWUgaXMgYWx3YXlzIGVtcHR5LCBpdCBtYXkgbm90IGJlIGEgcHJvYmxlbS4K IApXb3VsZCB5b3UgY2hlY2sgaXQ/CiAKVGhhbmsgeW91IHZlcnkgbXVjaC4KIApTaW5jZXJlbHkg WW91cnMsCiAKSWNrLVN1bmcgQ2hvaS4KCg== >From bruce.richardson@intel.com Wed Oct 7 13:04:18 2015 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 418165A64 for ; Wed, 7 Oct 2015 13:04:18 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 07 Oct 2015 04:04:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,648,1437462000"; d="scan'208";a="659509825" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.63]) by orsmga003.jf.intel.com with SMTP; 07 Oct 2015 04:04:15 -0700 Received: by (sSMTP sendmail emulation); Wed, 07 Oct 2015 12:04:14 +0025 Date: Wed, 7 Oct 2015 12:04:14 +0100 From: Bruce Richardson To: =?utf-8?B?7LWc7J217ISx?= Message-ID: <20151007110414.GA21348@bricha3-MOBL3> References: <47e2b06de73965fb579acd9170ae1f@cweb01.nm.nhnsystem.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47e2b06de73965fb579acd9170ae1f@cweb01.nm.nhnsystem.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Question about store_return() in ~/dpdk/lib/librte_distributor/rte_distributor.c 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, 07 Oct 2015 11:04:18 -0000 On Wed, Oct 07, 2015 at 06:07:23PM +0900, 최익성 wrote: > Dear DPDK experts. > > Thank you very much for your excellent efforts and contributions. > > I have a question about store_return() in ~/dpdk/lib/librte_distributor/rte_distributor.c > > The store_return() function adds a oldbuf packet to d->returns.mbuf[] queue. > > If the queue is full and the oldbuf packet is NULL, the queue seems to lost a packet in the queue without modifying ret_start/ret_count values. > > Is the last position of the queue always empty? > > Would you check it? > > > #define RTE_DISTRIB_MAX_RETURNS 128 > #define RTE_DISTRIB_RETURNS_MASK (RTE_DISTRIB_MAX_RETURNS - 1) > > /* stores a packet returned from a worker inside the returns array */ > static inline void > store_return(uintptr_t oldbuf, struct rte_distributor *d, > unsigned *ret_start, unsigned *ret_count) > { > /* store returns in a circular buffer - code is branch-free. buffer 끝에 oldbuf를 추가함 */ > d->returns.mbufs[(*ret_start + *ret_count) & RTE_DISTRIB_RETURNS_MASK] > = (void *)oldbuf; > *ret_start += (*ret_count == RTE_DISTRIB_RETURNS_MASK) & !!(oldbuf); > *ret_count += (*ret_count != RTE_DISTRIB_RETURNS_MASK) & !!(oldbuf); > } > > If d->returns.mbufs[] queue is full, oldbuf replaces the first cell of the queue (new packet overwrites the last packet in the queue). > > ret_start is preserved if the queue is not full (count!= MAX_VALUE(RTE_DISTRIB_RETURNS_MASK)) > if ret_start is MAX value and oldbuf is not NULL, ret_start is incremented by 1. > > ret_count is incremented by 1 if it is not MAX value and oldbuf is not NULL). > if ret_count is MAX value, ret_count is preserved. > > The mbufs queue is written by oldbuf(NULL) even though when the queue is full and the oldbuf packet is NULL (no packet insertion). > It may lost a cell in the queue. > If the last position of the queue is always empty, it may not be a problem. > > Would you check it? > > Thank you very much. > > Sincerely Yours, > > Ick-Sung Choi. > Hi, yes, it can overwrite entries in that array. When designing the library, there were two possible use cases taken into account: 1. The user did not want to return the packets to the distributor but pass them elsewhere from the workers when done. In this case, the overwriting did not matter. 2. The second case is where ordering is to be preserved, and here the user does want to pass them back to the distributor. To accomodate this, the buffer size is made considerably bigger than the default burst size, so that anyone who polls the ring after each burst (or even after each second burst) should again have no issues and avoid problems with overwriting the entry. Regards, /Bruce