From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E3479A0526; Mon, 20 Jan 2020 18:46:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 173241C18E; Mon, 20 Jan 2020 18:46:20 +0100 (CET) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id E45DA1C0D7 for ; Mon, 20 Jan 2020 18:46:18 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id c9so352573wrw.8 for ; Mon, 20 Jan 2020 09:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=75ut8hxlyaFx+7oM8Qu3PPc2R4cQ3ACqpV4D2x6qfUQ=; b=CvNS58YZcEFLeBembgFrI27ZgRnvLiiyMtYyRW5TEnPKozfboVFAbaqgbEGc5iFGzh EgcW1GxMZ7fOFTg7aGlN9D6ThEbNpN1TlH6D+4mUUr3QM8JaaF9Dk+stIr54z9Gyul5v Ra1XtvNhJDnD+pLaiwqDgQrMx9tqJ3Om/GWHSTeoyEJ13hIjmIKjEzoEeJQSgIMz8pkB JIYrDbiXFkPuy7ytQa7ZrVK8TZvJ7npKg7hxjijjlk1DdkB1a4ARkv805zoCHn/mnpQ3 vAKaJDY1v3u6v8o2lC2S1p0nPNT7J/rafmDsTqGWWYZ2jzTKN5Sf6mxenJgCDeZ0xrt8 IjXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=75ut8hxlyaFx+7oM8Qu3PPc2R4cQ3ACqpV4D2x6qfUQ=; b=RMJFdJYL20SjGsG0R1Dow0lReUjQuOQt9s+978DI9LnQcx9aSp1GP2fgUZ+0UeqhJG XWtWy+uEhfbXFMbu708Zrx0TnaBvYwpO1NvPVzgjBvUYuDLGMWkUqPrmqLXy30uYX97z TloLkswlnhzVmR/MR5XBd3c3UJpw4mlpkvGwDljuG72z5aoWVBq9HYEDURkqMh19DR7s QrYgjVW0SGBsGKQVDFVwTU6wsTkreBCv4DaUSbi4SH1JQeJDweDdZ5rAGz5lbCJJcLl9 orDg0roA3WddaNiL/P3xcQwyzJ84JGFZvKTEFeCP1nxOk0vvLCAgTCzn951fOMOv7tUy jh4A== X-Gm-Message-State: APjAAAUOGVJZpmsPpxAE+lSdKyNIky5tgJZ8MbIhDncsVGHJPA7EnqAQ 1nwGHAosUopzUw8P9MHLTRp+kw== X-Google-Smtp-Source: APXvYqyJ47JmvXD3uuHDJCQSZFeBLoJnQIRI7Z5tEwP5Yto1xUhA3kiDQrUI90dfreY5BxudHavKmQ== X-Received: by 2002:a5d:4acb:: with SMTP id y11mr692533wrs.106.1579542378561; Mon, 20 Jan 2020 09:46:18 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id t12sm48251597wrs.96.2020.01.20.09.46.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jan 2020 09:46:18 -0800 (PST) Date: Mon, 20 Jan 2020 18:46:17 +0100 From: Olivier Matz To: Viacheslav Ovsiienko Cc: dev@dpdk.org, matan@mellanox.com, rasland@mellanox.com, orika@mellanox.com, shahafs@mellanox.com, stephen@networkplumber.org, thomas@mellanox.net Message-ID: <20200120174617.GF22738@platinum> References: <20191118094938.192850-1-shahafs@mellanox.com> <1579541003-2399-1-git-send-email-viacheslavo@mellanox.com> <1579541003-2399-4-git-send-email-viacheslavo@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1579541003-2399-4-git-send-email-viacheslavo@mellanox.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v5 3/5] mbuf: create packet pool with external memory buffers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Jan 20, 2020 at 05:23:21PM +0000, Viacheslav Ovsiienko wrote: > The dedicated routine rte_pktmbuf_pool_create_extbuf() is > provided to create mbuf pool with data buffers located in > the pinned external memory. The application provides the > external memory description and routine initializes each > mbuf with appropriate virtual and physical buffer address. > It is entirely application responsibility to register > external memory with rte_extmem_register() API, map this > memory, etc. > > The new introduced flag RTE_PKTMBUF_POOL_F_PINNED_EXT_BUF > is set in private pool structure, specifying the new special > pool type. The allocated mbufs from pool of this kind will > have the EXT_ATTACHED_MBUF flag set and initialiazed shared > info structure, allowing cloning with regular mbufs (without > attached external buffers of any kind). > > Signed-off-by: Viacheslav Ovsiienko [...] > @@ -247,7 +439,7 @@ int rte_mbuf_check(const struct rte_mbuf *m, int is_header, > return 0; > } > > -/** > +/* > * @internal helper function for freeing a bulk of packet mbuf segments > * via an array holding the packet mbuf segments from the same mempool > * pending to be freed. It could be removed. [...] > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > index 7a41aad..eaeda04 100644 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -637,6 +637,13 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct rte_mempool *mp) > void rte_pktmbuf_init(struct rte_mempool *mp, void *opaque_arg, > void *m, unsigned i); > > +/** The context to initialize the mbufs with pinned external buffers. */ > +struct rte_pktmbuf_extmem_init_ctx { > + const struct rte_pktmbuf_extmem *ext_mem; /* descriptor array. */ > + unsigned int ext_num; /* number of descriptors in array. */ > + unsigned int ext; /* loop descriptor index. */ > + size_t off; /* loop buffer offset. */ > +}; Can this definition be private in the .c ? Apart from this, Acked-by: Olivier Matz