From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48BA5C2D0DB for ; Mon, 20 Jan 2020 14:11:14 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id D508C21835 for ; Mon, 20 Jan 2020 14:11:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D508C21835 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=6wind.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A4CCD322C; Mon, 20 Jan 2020 15:11:12 +0100 (CET) Received: from proxy.6wind.com (host.76.145.23.62.rev.coltfrance.com [62.23.145.76]) by dpdk.org (Postfix) with ESMTP id 7DFC32C6D for ; Mon, 20 Jan 2020 15:11:11 +0100 (CET) Received: from glumotte.dev.6wind.com (unknown [10.16.0.195]) by proxy.6wind.com (Postfix) with ESMTP id 3E3E036FA76; Mon, 20 Jan 2020 15:11:11 +0100 (CET) Date: Mon, 20 Jan 2020 15:11:11 +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: <20200120141111.GK14387@glumotte.dev.6wind.com> References: <20191118094938.192850-1-shahafs@mellanox.com> <1579179869-32508-1-git-send-email-viacheslavo@mellanox.com> <1579179869-32508-5-git-send-email-viacheslavo@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1579179869-32508-5-git-send-email-viacheslavo@mellanox.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v4 4/5] app/testpmd: add mempool with external data 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 Thu, Jan 16, 2020 at 01:04:28PM +0000, Viacheslav Ovsiienko wrote: > The new mbuf pool type is added to testpmd. To engage the > mbuf pool with externally attached data buffers the parameter > "--mp-alloc=xbuf" should be specified in testpmd command line. > > The objective of this patch is just to test whether mbuf pool > with externally attached data buffers works OK. The memory for > data buffers is allocated from DPDK memory, so this is not > "true" external memory from some physical device (this is > supposed the most common use case for such kind of mbuf pool). > > The user should be aware that not all drivers support the mbuf > with EXT_ATTACHED_BUF flags set in newly allocated mbuf (many > PMDs just overwrite ol_flags field and flag value is getting > lost). > > Signed-off-by: Viacheslav Ovsiienko > --- > app/test-pmd/config.c | 2 ++ > app/test-pmd/flowgen.c | 3 +- > app/test-pmd/parameters.c | 2 ++ > app/test-pmd/testpmd.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++ > app/test-pmd/testpmd.h | 4 ++- > app/test-pmd/txonly.c | 3 +- > 6 files changed, 92 insertions(+), 3 deletions(-) > > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c > index 9da1ffb..5c6fe18 100644 > --- a/app/test-pmd/config.c > +++ b/app/test-pmd/config.c > @@ -2395,6 +2395,8 @@ struct igb_ring_desc_16_bytes { > return "xmem"; > case MP_ALLOC_XMEM_HUGE: > return "xmemhuge"; > + case MP_ALLOC_XBUF: > + return "xbuf"; > default: > return "invalid"; > } > diff --git a/app/test-pmd/flowgen.c b/app/test-pmd/flowgen.c > index 03b72aa..ae50cdc 100644 > --- a/app/test-pmd/flowgen.c > +++ b/app/test-pmd/flowgen.c > @@ -199,7 +199,8 @@ > sizeof(*ip_hdr)); > pkt->nb_segs = 1; > pkt->pkt_len = pkt_size; > - pkt->ol_flags = ol_flags; > + pkt->ol_flags &= EXT_ATTACHED_MBUF; > + pkt->ol_flags |= ol_flags; > pkt->vlan_tci = vlan_tci; > pkt->vlan_tci_outer = vlan_tci_outer; > pkt->l2_len = sizeof(struct rte_ether_hdr); This shows that we have to be careful when using a mempool with external memory pinned mbufs. Maybe that's something that should be mentionned in the release note? That's not the first time I'm asking myself if ol_flags shouldn't be splitted in ol_flags and flags. Certainly something to think about for next ABI breakage release. Acked-by: Olivier Matz