From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 7C9F7282 for ; Fri, 16 Dec 2016 11:06:06 +0100 (CET) Received: by mail-wm0-f50.google.com with SMTP id a197so25579240wmd.0 for ; Fri, 16 Dec 2016 02:06:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TK5nLYp1u3z56vm3beL12TKie/1XG4LZ/itJUfPTif8=; b=loUB0ZLq4N6FuF/H/R8EGwpmTyFPFst6IVYssXZn3S0fhtOGiMH+AwYuigztMQtJGC ryNVNP33fmrm0R/2npp16ybLbz4DjyAeB65vEDCPkP7ayMNQg16Lj8yHolbjZRPW96UW ywVjz2AAp0vnNbk4ffr/WzlvX0qRAsJNGzKMhEUeWSt0aE99NPF1YdcNh2xC5HRQKjs2 7PDpb3WbnQQcKcl4GJ1L1r5eq4wJ6Xza9oyLhz4DSBLKTE0KVW0vcbx29LZkwUkFlL2e OtZQkfAGVhq8IBzqkC895yauMqlXcG/WoeKr8qXeDZGrh3qwNaJUyFnK6Xo9bJz0vDpI SEjQ== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=TK5nLYp1u3z56vm3beL12TKie/1XG4LZ/itJUfPTif8=; b=Cnf7E7zjsB39c9azg5O18cO/XFiD2XT7TGWOOv9aFdiiJS2GOTtc6DKVADkpijH0RV sFeI3bdAoCUDhsN3UotpilXUp2OGDngMgA1cGp+nhH3qoc8m8uyT3Jx36QPkaXR8J5zw FKrtVq9IVsgw04TSBVsEV0Fiv8KS6SVlmFjd6hpJX8U48xoMnFLC+QW0Sujvm6e20dqC 8w3hObwKJu/2fZBJzQ718p8hH9HTd4Q7mixJaQ/7tjSK75fHhi029nE6BP7P+NDmR6iI 2TdpfzzwvvuEPLtiCOT0bWZbUU0ZSk20nEzUWFIFM6fW6ciRP4gHwi6IZLQdrXVUD8q5 xiEQ== X-Gm-Message-State: AIkVDXIRUaUASedBNPKc3d4atK3e6BCYgLFCyAv5SqpmxszHnjplu3XF9kfITlBo3OZ3CLWY X-Received: by 10.28.227.9 with SMTP id a9mr2077267wmh.85.1481882766174; Fri, 16 Dec 2016 02:06:06 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id 197sm2599182wmy.16.2016.12.16.02.06.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 16 Dec 2016 02:06:06 -0800 (PST) Date: Fri, 16 Dec 2016 11:06:04 +0100 From: Olivier Matz To: Tomasz Kulasek Cc: dev@dpdk.org Message-ID: <20161216110604.7097488e@platinum> In-Reply-To: <1480698466-17620-2-git-send-email-tomaszx.kulasek@intel.com> References: <1480698466-17620-1-git-send-email-tomaszx.kulasek@intel.com> <1480698466-17620-2-git-send-email-tomaszx.kulasek@intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/4] rte_mbuf: add rte_pktmbuf_coalesce 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: , X-List-Received-Date: Fri, 16 Dec 2016 10:06:06 -0000 Hi Tomasz, On Fri, 2 Dec 2016 18:07:43 +0100, Tomasz Kulasek wrote: > This patch adds function rte_pktmbuf_coalesce to let crypto PMD > coalesce chained mbuf before crypto operation and extend their > capabilities to support segmented mbufs when device cannot handle > them natively. > > > Signed-off-by: Tomasz Kulasek > --- > lib/librte_mbuf/rte_mbuf.h | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > index ead7c6e..f048681 100644 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -1647,6 +1647,40 @@ static inline int rte_pktmbuf_chain(struct > rte_mbuf *head, struct rte_mbuf *tail } > > /** > + * Coalesce data from mbuf to the continuous buffer. > + * > + * @param mbuf_dst > + * Contiguous destination mbuf > + * @param mbuf_src > + * Uncontiguous source mbuf > + * > + * @return > + * - 0, on success > + * - -EINVAL, on error > + */ I think the API should be clarified. In your case, it is expected that the destination mbuf is already filled with uninitialized data (i.e. that rte_pktmbuf_append() has been called). We could wonder if a better API wouldn't be to allocate the dst mbuf in the function, call append()/prepend(), and do the copy. Even better, we could have: int rte_pktmbuf_linearize(struct rte_mbuf *m) It will reuse the same mbuf (maybe moving the data). > + > +#include This should be removed. > + > +static inline int > +rte_pktmbuf_coalesce(struct rte_mbuf *mbuf_dst, struct rte_mbuf *mbuf_src) { Source mbuf should be const. > + char *dst; > + > + if (!rte_pktmbuf_is_contiguous(mbuf_dst) || > + rte_pktmbuf_data_len(mbuf_dst) >= > + rte_pktmbuf_pkt_len(mbuf_src)) > + return -EINVAL; Why >= ? > + > + dst = rte_pktmbuf_mtod(mbuf_dst, char *); > + > + if (!__rte_pktmbuf_read(mbuf_src, 0, rte_pktmbuf_pkt_len(mbuf_src), > + dst)) When a function returns a pointer, I think it is clearer to do: if (func() == NULL) than: if (!func()) > + return -EINVAL; > + > + return 0; > +} > + > +/** > * Dump an mbuf structure to a file. > * > * Dump all fields for the given packet mbuf and all its associated One more question, I don't see where this function is used in your patchset. What is your use-case? Regards, Olivier