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 7A353A04B9; Mon, 11 Nov 2019 16:25:06 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C59A627D; Mon, 11 Nov 2019 16:25:05 +0100 (CET) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by dpdk.org (Postfix) with ESMTP id 09826235 for ; Mon, 11 Nov 2019 16:25:04 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D52425FE; Mon, 11 Nov 2019 10:25:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 11 Nov 2019 10:25:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=5A1FObsQ8ws0K7fOdHd6j3UZTXNHmWK6DUq7psdKoxk=; b=PNdv/uOsjnMC gZu0ris2MgLr2imO0RuAgieLXPyq5DtbdhYrsOXVwJar2QgR2tAX4lyoOfXcxrjs gBlLjI+XkRu79xr/ZbealGawG1wjjcF0+TI9Bgysg/kgEQVnnjhG7r+NmIhfdcMc T/E3BWdYJAJPISmGo+ndlu73xJFFNew= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=5A1FObsQ8ws0K7fOdHd6j3UZTXNHmWK6DUq7psdKo xk=; b=M1eAMBlOaOQ5LEv96uot3sC5U79eOa8eIwtYokvvLZhUx8QW1gbqflMOS lgw65QQA6CTMl2mD8idXmGSfCieMMoE3cevkl/IyT1hQsdIGB/9TVOfB5n+p3jRS 0CfblEOj+zvcmF0PK1G7f225v5fQivpc83W/SxJcnXtHQk7owRSy02TkZBeuTYld QhFNk8oQjmHz5nsulGBdfWZhwK8t9ggI9axzMXtTJXGdU1Zj1rTBPojN89kajc1h QiGrD5LIFUooku4OFKfJahb6TxCDfr3+hhSeXAsY9oCz6jRxnIu6tAzEmHNfJTM7 iExikS9VmChqNkxKFGmO+3iUEL/CA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvjedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeefjedrudejfedrgeejrddufeeinecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (unknown [37.173.47.136]) by mail.messagingengine.com (Postfix) with ESMTPA id DD08080059; Mon, 11 Nov 2019 10:24:53 -0500 (EST) From: Thomas Monjalon To: Jakub Grajciar Cc: dev@dpdk.org, Ferruh Yigit , David Marchand , Anatoly Burakov Date: Mon, 11 Nov 2019 16:24:47 +0100 Message-ID: <3129101.eYSCb3BGBK@xps> In-Reply-To: References: <20190822081833.11203-1-jgrajcia@cisco.com> <20191104110300.8369-1-jgrajcia@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6] net/memif: zero-copy slave 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" 11/11/2019 16:21, Ferruh Yigit: > On 11/4/2019 11:03 AM, Jakub Grajciar wrote: > > Zero-copy slave support for memif PMD. > > Slave interface exposes DPDK memory to > > master interface. Only single file segments > > are supported (EAL option --single-file-segments). > > > > Signed-off-by: Jakub Grajciar > > --- > > doc/guides/nics/memif.rst | 42 +- > > drivers/net/memif/Makefile | 1 + > > drivers/net/memif/memif_socket.c | 65 +-- > > drivers/net/memif/meson.build | 1 + > > drivers/net/memif/rte_eth_memif.c | 449 +++++++++++++++++- > > drivers/net/memif/rte_eth_memif.h | 11 +- > > lib/librte_eal/common/eal_common_mcfg.c | 7 + > > .../common/include/rte_eal_memconfig.h | 13 + > > lib/librte_eal/rte_eal_version.map | 1 + > > 9 files changed, 516 insertions(+), 74 deletions(-) > > net/memif part looks good to me, > > @David, @Anatoly, any concern on new eal API, is it good to go? I didn't get into details of this PMD, but requesting an EAL property looks strange to me. Is memif using directly some EAL memory? Or is it using memory from mempool? If it is from mempool, then the property should be requested to mempool. Reminder: mempool memory is not always from EAL.