From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id EA7AF1B259 for ; Fri, 6 Oct 2017 10:39:40 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 57AC72016D; Fri, 6 Oct 2017 04:39:40 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 06 Oct 2017 04:39:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=4RzPzOE+C+65jnx KjfaTklpl9r2RmGWQjrjnz1czLXY=; b=ll0tHzqiakinH3Y0iXbibRefpmYLRKJ saMRnYJSQNjAVv5s9iL8tsu7gNiHwX9NMhSau0/SQluKcarjJO5V34Xyz++tn2Vy AKeXT9Xboo9XEiSxpD0/fndtpMygHynstS5Zlgi/WW7Hb7OeC3xGBXahoHxAv6Tw +qkO9KXGuuxc= 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=4RzPzOE+C+65jnxKjfaTklpl9r2RmGWQjrjnz1czLXY=; b=A0YmY4+W GlEgcL4X3rlgEXvtq6dgPJPE/CeJeI6cApfcwrLkcuUEzg5KRlyP2lm1OVctJ6Jz XFDKcrT1+tdQ019adF+vDD7DaNRKe1zmn1VDbS21C6gAD+enTCgEpFGdp25f5e47 ntxnGtrz+TWaKeRHKIFXYh0C9403NGDLbFUreUCqefr7oukptnZgD79raolsTi0x FQK7MZ2KdVSB+Cc7p2kKMlN6qlUDpopNrcpT7bTahe852IjJXN+3WIstO8yojQmS svHbh+1kAhZEvA2WyhHuNdvHaeacpsyBRIPBC9CAthdR0XLlQm0IWWUCZp19aeBS NNQ6kF3NhsPIZw== X-ME-Sender: X-Sasl-enc: +qdveSZLPcv2usIjm/axzhXbC+3fjzkozFHGYV5hQ3nz 1507279180 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0473F2479F; Fri, 6 Oct 2017 04:39:40 -0400 (EDT) From: Thomas Monjalon To: santosh Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com Date: Fri, 06 Oct 2017 10:39:39 +0200 Message-ID: <16755451.xTlTRoHbfF@xps> In-Reply-To: <838da98a-47aa-efce-fb98-304e236fa5c6@caviumnetworks.com> References: <20170911151837.25092-1-santosh.shukla@caviumnetworks.com> <1712938.NqKmOO8lQc@xps> <838da98a-47aa-efce-fb98-304e236fa5c6@caviumnetworks.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 1/2] eal: allow user to override default pool handle 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, 06 Oct 2017 08:39:41 -0000 06/10/2017 05:31, santosh: > > On Friday 06 October 2017 05:59 AM, Thomas Monjalon wrote: > > 01/10/2017 11:14, Santosh Shukla: > >> --- a/lib/librte_eal/common/eal_common_options.c > >> +++ b/lib/librte_eal/common/eal_common_options.c > >> @@ -98,6 +98,7 @@ eal_long_options[] = { > >> {OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM }, > >> {OPT_VMWARE_TSC_MAP, 0, NULL, OPT_VMWARE_TSC_MAP_NUM }, > >> {OPT_XEN_DOM0, 0, NULL, OPT_XEN_DOM0_NUM }, > >> + {OPT_MBUF_POOL_OPS_NAME, 1, NULL, OPT_MBUF_POOL_OPS_NAME_NUM}, > >> {0, 0, NULL, 0 } > >> }; > > I think the options were sorted alphabetically. > > This is most logical comment so far I got from you. I will imagine you did not really write this. > Yes' will do. posting v6. Thanks. > > > [...] > >> --- a/lib/librte_eal/common/eal_internal_cfg.h > >> +++ b/lib/librte_eal/common/eal_internal_cfg.h > >> @@ -82,7 +82,7 @@ struct internal_config { > >> volatile enum rte_intr_mode vfio_intr_mode; > >> const char *hugefile_prefix; /**< the base filename of hugetlbfs files */ > >> const char *hugepage_dir; /**< specific hugetlbfs directory to use */ > >> - > >> + const char *mbuf_pool_ops_name; /**< mbuf pool ops name */ > > Why this config is not stored in mbuf.c? > > > Why the config not stored for vfio? hugepage? etc..in that case applicable too. All other configs are related to EAL features. > This is correct place to keep for now, unless as discussed in dpdksummit about eal > parsing abstraction approach.. plugin style approach so that each module has its own > parser. till then It should sit here like other, Its blocker for external-mempool > in general case: Where users are forced to hard-code their handle in _OPS_DEFAULT_=. You probably missed that mbuf is not part of EAL. I'm not talking about parsers, just where to save a variable. You store mbuf info in EAL, and later, call rte_eal_mbuf_default_mempool_ops() from mbuf lib. It would be saner to directly save it in mbuf lib. But Olivier agreed to save mbuf config in EAL. I won't discuss it anymore if you don't want to change.