From patchwork Mon Jan 5 12:22:06 2015 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: 42733 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-lb0-f199.google.com (mail-lb0-f199.google.com [209.85.217.199]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 7659725B5B for ; Mon, 5 Jan 2015 12:22:29 +0000 (UTC) Received: by mail-lb0-f199.google.com with SMTP id z12sf6203649lbi.6 for ; Mon, 05 Jan 2015 04:22:28 -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=ExkMYNJrQaU0GFObga6Gc1oAMy+UEywoa1qvO7WBu3k=; b=isgRyq3+NGNx2sYQLuGBQrikUY98t7hFpiWgAT22bW3gpddjgopTtxVdtic5F1XyUM BqRRUhR7mF+n4E5wjOMh+z4+yaDyxXwVYhCFLOc4G2TEUvNMw00BOifrZ7QGESqXclK3 5Hipf1r5FEgnH6zqN/+O/dI6u7qjggG5wDdwvqRfqkhcyvEdLCESVILyhtvbOl0MBy/S TgVahtmSu/4U/vXKTF2ggr5qEuSyCR+PYGHgSJ3Wq21VMIp8MAktKuUsoNlWCKqlKICd E9/DOa22sstXaYL01Pu8FNVVN9oBjqWwr0HF36WfNUBznLxf27LJHNrhaOW756cZu/l9 hJ6g== X-Gm-Message-State: ALoCoQkcPBnFREEGvsEtzKB3Oi90cwDYSKQGkNDb5ke1Hhjj7HYAlU+wMvNWrJ0CaLKPISs29zBt X-Received: by 10.180.82.34 with SMTP id f2mr1433220wiy.1.1420460548347; Mon, 05 Jan 2015 04:22:28 -0800 (PST) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.205.38 with SMTP id ld6ls2658541lac.50.gmail; Mon, 05 Jan 2015 04:22:28 -0800 (PST) X-Received: by 10.112.170.36 with SMTP id aj4mr91270630lbc.3.1420460548072; Mon, 05 Jan 2015 04:22:28 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com. [209.85.215.44]) by mx.google.com with ESMTPS id ra8si61656955lbb.12.2015.01.05.04.22.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Jan 2015 04:22:28 -0800 (PST) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.44 as permitted sender) client-ip=209.85.215.44; Received: by mail-la0-f44.google.com with SMTP id gd6so18214138lab.31 for ; Mon, 05 Jan 2015 04:22:28 -0800 (PST) X-Received: by 10.112.170.36 with SMTP id aj4mr91270620lbc.3.1420460547903; Mon, 05 Jan 2015 04:22:27 -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.9.200 with SMTP id c8csp865625lbb; Mon, 5 Jan 2015 04:22:26 -0800 (PST) X-Received: by 10.229.24.6 with SMTP id t6mr65808073qcb.17.1420460545908; Mon, 05 Jan 2015 04:22:25 -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 i47si29813298qgd.126.2015.01.05.04.22.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 05 Jan 2015 04:22:25 -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 1Y86ft-0004Ft-AL; Mon, 05 Jan 2015 12:22:21 +0000 Received: from demumfd001.nsn-inter.net ([93.183.12.32]) by ip-10-35-177-41.ec2.internal with esmtp (Exim 4.76) (envelope-from ) id 1Y86fm-0004Fl-Uk for lng-odp@lists.linaro.org; Mon, 05 Jan 2015 12:22:15 +0000 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t05CM7LO024060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2015 12:22:07 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t05CM7XK022616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 13:22:07 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 5 Jan 2015 13:22:07 +0100 Received: from DEMUMBX012.nsn-intra.net ([169.254.12.252]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 13:22:07 +0100 From: "Savolainen, Petri (NSN - FI/Espoo)" To: ext Bill Fischofer Thread-Topic: [lng-odp] [PATCH v2 1/2] api: buffer_pool: Correct buf_size pool param documentation Thread-Index: AQHQHrAZ20uq9qWsXUiyQMV2jlyZbJyxZPFg Date: Mon, 5 Jan 2015 12:22:06 +0000 Message-ID: References: <1419334146-28747-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.115] 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: 24974 X-purgate-ID: 151667::1420460528-00002DC5-995E72CF/0/0 X-Topics: patch Cc: lng-odp-forward Subject: Re: [lng-odp] [PATCH v2 1/2] 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.44 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: Tuesday, December 23, 2014 2:58 PM To: Petri Savolainen Cc: lng-odp-forward Subject: Re: [lng-odp] [PATCH v2 1/2] api: buffer_pool: Correct buf_size pool param documentation On Tue, Dec 23, 2014 at 5:29 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 | 28 +++++++++++++--------- 1 file changed, 17 insertions(+), 11 deletions(-) + this is the total number of segments and the + maximum number of packets (in case that all + packets have a single segment). */ This is not what the implementation needs to know. A buffer is not a segment since a buffer is what anchors the metadata associated with the object. Whether or not we introduce packet segment metadata, packets (single object) have metadata associated with them that are independent of the number of segments they occupy. Conflating these concepts doesn't simplify anything and just confuses the terminology and APIs. Implementation needs to know this. As it says above, in the worst case all packets in the pool have only single segment and thus the max number of packet metadata objects is ‘num_bufs’. Number of segments per packet is not a constant, it depends on received packet lengths (and fluctuates with those) It’s an implementation detail if buffer/packet metadata is stored separately from actual buffer space (or next to it). Typically it’s stored next to the buffer space so that the first cache line of the packet covers both the metadata and the first N bytes of packet data/headroom. When packet consists of multiple segments, the first segment holds per packet meta-data, other segments hold just pointers to the data and next segments. The previous linux-generic implementation was designed like that. -Petri 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 8380ac1..9329405 100644 --- a/platform/linux-generic/include/api/odp_buffer_pool.h +++ b/platform/linux-generic/include/api/odp_buffer_pool.h @@ -35,19 +35,25 @@ 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 num_bufs; /**< Number of buffers in the pool */ + uint32_t buf_size; /**< Minimum buffer size in bytes. For packets, + this is the minimum segment buffer length, + which includes possible head-/tailroom bytes. + Use 0 for the default size of the buffer type + (e.g. for timeouts or min packet segment + length).*/ I continue to have difficulty with understanding how the implementation is expected to use this interpretation of buf_size to calculate how much storage should be reserved for the buffer pool. The implementation needs to know this and under the former definition that was straightforward since the application was specifying how large each buffer may be. Minimums do not do this. Application specifies the minimum size (e.g. 100 bytes). Implementation can round it up to a sensible value (e.g. 128 bytes). odp_buffer_size() and odp_packet_seg_buf_len() return the actual buffer length (e.g. 128 bytes). Pool size is num_bufs * (buf_size + round up + internal headers, per buffer overheads, etc). + 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. For packets,