From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 293ED530F for ; Mon, 14 Mar 2016 15:46:50 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id l68so111075439wml.0 for ; Mon, 14 Mar 2016 07:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=vCxoEuXIPFiHJ85gwCtB1KP0IRKK8xR99/BnNB3Ta7E=; b=V4hnqVde9zUZsr/H8qyu6yNRjP9PtDkCpP1rsLGcZZlowMesx819aiv+mxmAvlp/CS 8iV/DbjV1rpu+ID88HIGm4lTKbSQYOQoulqryOXVDI0GDBj4pyVLtzvWuvcn/81hgun/ ieuBBu1uszbi4YEQLWPXARibjCTftREPp91Fotin4giA+gQ4wtDAe2KOWLw5pXa9VjrX Ny5GHxyjtLTka1rB5yShHI7zZnAH1tWvBO7y1T2cNyGHzRzynsHc7eD5p8umEpgBmla2 7meeF35JNyN2fxeQ3fVxgtUDog45s4eCJdeguV1JTZaNDYDlgB6H/7laAAx06CUVrKth SjKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=vCxoEuXIPFiHJ85gwCtB1KP0IRKK8xR99/BnNB3Ta7E=; b=lIcgxSCS0E85V+NUIAr4+RPrX6q5AAzOyB6UhWe+kKl6WaKOJLlytuf8QCW0BTJYzw ES+/faFlztPEcodbprWAiUVTS/h3zA6KcVCknO9PKbceZwn8NmT6QVdQXsIcjKCavEzQ nUC6Bzrq2qAdLdhZHXiLTVrRErSiamPV98bmvFLLMBeoL0nD20gP3PinNKTCgb1vqq/X rkzP7hx44lI41l4HDQXBn5rMbWCtDIL9KmvkX0dPq29JeSd8xCs0Y58zWpC4TVsIZ0ON 7kYnBNYvfGySgWWOkII0bmW3v29ICH4XhNoAWfP/8wgVUXadm50ArZS85I5b9rBfO9TV dZmQ== X-Gm-Message-State: AD7BkJLpG+OhadMxh2TMfHziCyFuIRlc0uuu8xFy4eDqC6K14dy+gcghsrE+1d2M+U5F2o5v X-Received: by 10.28.17.141 with SMTP id 135mr19329601wmr.48.1457966810007; Mon, 14 Mar 2016 07:46:50 -0700 (PDT) Received: from xps13.localnet (91.111.75.86.rev.sfr.net. [86.75.111.91]) by smtp.gmail.com with ESMTPSA id pd1sm22606181wjb.19.2016.03.14.07.46.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 07:46:48 -0700 (PDT) From: Thomas Monjalon To: "Traynor, Kevin" Cc: dev@dpdk.org, "nakajima.yoshihiro@lab.ntt.co.jp" , "mst@redhat.com" , "p.fedin@samsung.com" , "ann.zhuangyanying@huawei.com" Date: Mon, 14 Mar 2016 15:45:25 +0100 Message-ID: <22781410.CoInzAJ6Km@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <2329500.UVQ1bbgajc@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 14:46:50 -0000 2016-03-14 13:53, Traynor, Kevin: > From: Thomas Monjalon > > 2016-03-08 17:04, Yuanhan Liu: > > > On Tue, Mar 08, 2016 at 10:49:30AM +0200, Panu Matilainen wrote: > > > > On 03/07/2016 03:13 PM, Yuanhan Liu wrote: > > > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the IVSHMEM > > config > > > > uses, getting rid of it (by replacing with a runtime switch) would be > > great. > > > > > > Can't agree more. > > > > +1 > > > > > > OTOH IVSHMEM itself seems to have fallen out of the fashion since the > > memnic > > > > driver is unmaintained and broken since dpdk 2.0... CC'ing the IVSHMEM > > > > maintainer in case he has thoughts on this. > > > > The ivshmem config was not used for memnic which was using ivshmem only for > > data path. > > CONFIG_RTE_LIBRTE_IVSHMEM and CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS are more > > about full memory sharing. > > I have the feeling it could be dropped. > > It there are some users, I'd like to see a justification and a rework to > > remove these build options. > > Just to clarify - is this suggesting the removal of the IVSHMEM library itself, > or just some of the config options? I have no strong opinion about the library. About the config options, yes they should be removed. Note that they are not documented, so we don't really know the motivation to have them. > The reason I ask is that although we don't currently use it in OVS with DPDK, > I've seen at least one person using it in conjunction with the ring interface. > There may be others, so I want to cross-post if there's a deprecation discussion. Thank you for sharing.