From patchwork Mon Dec 22 11:56:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Savolainen, Petri \(NSN - FI/Espoo\)" X-Patchwork-Id: 42519 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-la0-f70.google.com (mail-la0-f70.google.com [209.85.215.70]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id D70C12188F for ; Mon, 22 Dec 2014 11:57:19 +0000 (UTC) Received: by mail-la0-f70.google.com with SMTP id hs14sf2811605lab.9 for ; Mon, 22 Dec 2014 03:57:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:from:to:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version:cc:subject:precedence:list-id :list-unsubscribe:list-archive:list-post:list-help:list-subscribe :content-type:errors-to:sender:x-original-sender :x-original-authentication-results:mailing-list; bh=qTb33KtlI+p9mEUhDR04ly8DhcGs2rLMV7/Gmcqt/Dc=; b=k2UkU+I7yrcQ4aFqmDt36sq9xVF7pWpbJpwu6evbZg6JPbNNC/iC3tbxBP/+4AOcXE ptjscwZjVCmYVIYZNqFstnp+cw3qXxrGeV8HnFJvr9oG7cCK4ILZYBKyN9E3XlDLS3B4 ifNJ5PEIOAoBPn/VnkroEJKSw0gHcyA1PzWYmyoAzmbzLdq64/KCfIAIR7zn4M7/I1x2 hK3TMhj462aj2sOpikeM10032plZ7vJMqL+SVCR3ZbLWGuC5h12OuhALvaeS8fJNZTNx Z7oOLzn3roQdDz18KwTQjSOY/ZfZbM/CN8k7MwtNX+a9m0JHTndqlLlbgNbGbDdzzkGt s/Dg== X-Gm-Message-State: ALoCoQnItm6RBscjnvv8nTURKjZP1mYtfaShTSkHMkEUIJ52docpX6dWFzFCP2ZEs8EWe7HmViXS X-Received: by 10.112.235.231 with SMTP id up7mr2730965lbc.0.1419249438379; Mon, 22 Dec 2014 03:57:18 -0800 (PST) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.28.67 with SMTP id z3ls1338437lag.2.gmail; Mon, 22 Dec 2014 03:57:18 -0800 (PST) X-Received: by 10.112.183.197 with SMTP id eo5mr21496664lbc.81.1419249438129; Mon, 22 Dec 2014 03:57:18 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com. [209.85.215.46]) by mx.google.com with ESMTPS id h3si12559295laa.49.2014.12.22.03.57.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Dec 2014 03:57:18 -0800 (PST) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.46 as permitted sender) client-ip=209.85.215.46; Received: by mail-la0-f46.google.com with SMTP id q1so3941334lam.33 for ; Mon, 22 Dec 2014 03:57:18 -0800 (PST) X-Received: by 10.152.87.100 with SMTP id w4mr21647972laz.71.1419249437972; Mon, 22 Dec 2014 03:57:17 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.142.69 with SMTP id ru5csp1001811lbb; Mon, 22 Dec 2014 03:57:17 -0800 (PST) X-Received: by 10.229.124.4 with SMTP id s4mr35628367qcr.11.1419249436055; Mon, 22 Dec 2014 03:57:16 -0800 (PST) Received: from ip-10-35-177-41.ec2.internal (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTPS id e60si19727999qga.116.2014.12.22.03.57.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 22 Dec 2014 03:57:16 -0800 (PST) Received-SPF: none (google.com: lng-odp-bounces@lists.linaro.org does not designate permitted sender hosts) client-ip=54.225.227.206; Received: from localhost ([127.0.0.1] helo=ip-10-35-177-41.ec2.internal) by ip-10-35-177-41.ec2.internal with esmtp (Exim 4.76) (envelope-from ) id 1Y31bq-0006H4-U1; Mon, 22 Dec 2014 11:57:10 +0000 Received: from demumfd002.nsn-inter.net ([93.183.12.31]) by ip-10-35-177-41.ec2.internal with esmtp (Exim 4.76) (envelope-from ) id 1Y31bk-0006F1-0H for lng-odp@lists.linaro.org; Mon, 22 Dec 2014 11:57:04 +0000 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBMBuuon017003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Dec 2014 11:56:56 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBMBuuXu008364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 12:56:56 +0100 Received: from DEMUMBX012.nsn-intra.net ([169.254.12.252]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 12:56:56 +0100 From: "Savolainen, Petri (NSN - FI/Espoo)" To: ext Bill Fischofer Thread-Topic: [lng-odp] [PATCH 1/3] api: buffer_pool: Correct buf_size pool param documentation Thread-Index: AQHQG6Yd2fdjVu4Y/0Ss/7adK23h85ybZPrA Date: Mon, 22 Dec 2014 11:56:56 +0000 Message-ID: References: <1419002899-17314-1-git-send-email-petri.savolainen@linaro.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.102] MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 27242 X-purgate-ID: 151667::1419249417-00001177-E48A6A46/0/0 X-Topics: patch Cc: lng-odp-forward Subject: Re: [lng-odp] [PATCH 1/3] api: buffer_pool: Correct buf_size pool param documentation X-BeenThere: lng-odp@lists.linaro.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: , List-Help: , List-Subscribe: , Errors-To: lng-odp-bounces@lists.linaro.org Sender: lng-odp-bounces@lists.linaro.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: petri.savolainen@nsn.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.46 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] Sent: Friday, December 19, 2014 6:09 PM To: Petri Savolainen Cc: lng-odp-forward Subject: Re: [lng-odp] [PATCH 1/3] api: buffer_pool: Correct buf_size pool param documentation On Fri, Dec 19, 2014 at 9:28 AM, Petri Savolainen > wrote: Buf_size parameter defines minimum buffer/segment length. Use 0 for default length. Signed-off-by: Petri Savolainen > --- .../linux-generic/include/api/odp_buffer_pool.h | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) Beyond this, as we discussed yesterday, a portable application really has no idea what segment sizes are being used by the underlying implementation, nor should it care. The only application-observable impact of segmentation is on packet addressability. As written, this spec precludes an SoC that has fixed-sized HW-managed segments from being ODP compliant. You've argued that an implementation can restrict acceptable values for this parameter but then the application is just echoing back the ODP_CONFIG variables here, so what is the point of this variable? Most SoCs do not have tight limitations for segment size. When limits are defined with standard config defines, application can adapt to those limits and optimize segmentation for its use cases when limitations are loose (in the common case). The purpose of buf_size and num_bufs is to allow the implementation to calculate the amount of storage it needs to reserve to support the buffer pool. So if an application says "I want N buffers of maximum size S" that makes sense. Saying "I want N things that will be divided into some unspecified number of segments of size S" is ambiguous because N is no longer determinate (this was one of the design issues with the original buffer pool implementation). So if num_bufs is no longer determinate, what is it's purpose? It needs more documentation, but for packets it’s total number of segments (for raw buffers and timers it’s number of those things). At the same time, it’s the total number of packets (of single segment). If it would be the total number of any size packets, segmentation would not improve memory usage (which it should do) since implementations would need to reserve memory for the worst case (all packets being the max size) anyway. -Petri + uint32_t buf_align; /**< Minimum buffer alignment in bytes. Valid values + are powers of two. Use 0 for default + alignment. Default will always be a multiple + of 8. */ uint32_t num_bufs; /**< Number of buffers in the pool */ int buf_type; /**< Buffer type */ } odp_buffer_pool_param_t; -- 2.2.1 _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp diff --git a/platform/linux-generic/include/api/odp_buffer_pool.h b/platform/linux-generic/include/api/odp_buffer_pool.h index 4da5f84..27e816d 100644 --- a/platform/linux-generic/include/api/odp_buffer_pool.h +++ b/platform/linux-generic/include/api/odp_buffer_pool.h @@ -35,18 +35,19 @@ extern "C" { /** * Buffer pool parameters * Used to communicate buffer pool creation options. + * + * @see ODP_CONFIG_PACKET_BUF_LEN_MIN, ODP_CONFIG_BUFFER_ALIGN_MIN, + * ODP_CONFIG_BUFFER_ALIGN_MAX */ typedef struct odp_buffer_pool_param_t { - uint32_t buf_size; /**< Buffer size in bytes. The maximum - number of bytes application will - store in each buffer. For packets, this - is the maximum packet data length, and - configured headroom and tailroom will be - added to this number */ - uint32_t buf_align; /**< Minimum buffer alignment in bytes. - Valid values are powers of two. Use 0 - for default alignment. Default will - always be a multiple of 8. */ + uint32_t buf_size; /**< Minimum buffer length in bytes. For packets, + this is the minimum segment buffer length. The + length includes head-/tailroom bytes. Use 0 for + default length. */ This is confusing. Presumably for buffers of type ODP_BUFFER_TYPE_PACKET this is a synonym for ODP_CONFIG_PACKET_BUF_LEN_MIN. However, how is a 0 value to be interpreted for other buffer types? Need to specify that here. In the current code it is legitimate to specify a buf_size of zero as that means that buffers will consist only of metadata. Buffers of type ODP_BUFFER_TYPE_TIMEOUT fall into that category, for example. Since this is a buffer structure, not a packet structure, the documentation should reflect that. User should use zero when - the buffer type has only meta-data - user is going to use the default segment size for packets (== PACKET_BUF_LEN_MIN)