From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 6BEA12935 for ; Wed, 5 Jul 2017 01:01:33 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 845F821C27; Tue, 4 Jul 2017 19:01:32 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 04 Jul 2017 19:01:32 -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=lpBXiaaSaCrazUU PJOzOO1MLfsXd3P8pKslOJX1XA/c=; b=fDIafonKjKIyDLDKG9oJXrg/IMWnEZv B3O6eu+JonxISxdWRF04onKUWAAsGEQiTyjl805jOeNKfGIghmoO4cS1RILId0k0 UUuj8QoSS88mrlSU1B/93T1NN8fg3CnF6EgrgyoXwbKBMTr557KVJsUoZwTqRiev S1kt4zJI1JXQ= 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=lpBXiaaSaCrazUUPJOzOO1MLfsXd3P8pKslOJX1XA/c=; b=PxaHkCdq 88+40AM3Nej16I/m91WhIejNkHOoS2rCP8EhVoYAsuzu9HFw1os54cSAPEeUFjMB 1T92igWIj9OkDYxBkCJjiFNCaWjtD7++RzEREm+cNnyAuxZ9O8MWhTCD+mXuP6MA qXtNcnZFiCK/HV55UVKoXzGUAD8qE3wBsPiT3O4b81kL1KmhE2LGf2bW2egvsrNy NlqB/ySIbrv8blnm6XEWtdg41RdBJZAz3GWwDA3NXExpKrTx9m7klwztaMg47mIb 5YuP6kwvkyCqNNXwCChDkfQhLwdVhhAMvoi44YwSUxQLE5bOSvesPSX4ZoZHxkdB /QzUPAM1+/Eraw== X-ME-Sender: X-Sasl-enc: RQqroRndRk2Vdr5egKZEX+Z3QHK95IMkiUGb+7uPaVtc 1499209292 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 39B1C7E6B1; Tue, 4 Jul 2017 19:01:32 -0400 (EDT) From: Thomas Monjalon To: Gaetan Rivet Cc: dev@dpdk.org Date: Wed, 05 Jul 2017 01:01:31 +0200 Message-ID: <30613628.0y91ajZ5LG@xps> In-Reply-To: <7052a1a87238f7a1f184b4a853c4fb73c564d3ab.1498001626.git.gaetan.rivet@6wind.com> References: <7052a1a87238f7a1f184b4a853c4fb73c564d3ab.1498001626.git.gaetan.rivet@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 10/19] bus: introduce bus scan policies 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: Tue, 04 Jul 2017 23:01:33 -0000 21/06/2017 01:35, Gaetan Rivet: > Scan policies describe the way a bus should scan the system to search > for possible devices. > > Three flags are introduced: > RTE_BUS_SCAN_UNDEFINED: Configuration is irrelevant for this bus > RTE_BUS_SCAN_WHITELIST: Scanning should be limited to declared devices > RTE_BUS_SCAN_BLACKLIST: Scanning should exclude only declared devices > > Signed-off-by: Gaetan Rivet [...] > @@ -148,6 +164,7 @@ struct rte_bus { > rte_bus_plug_t plug; /**< Probe single device for drivers */ > rte_bus_unplug_t unplug; /**< Remove single device from driver */ > rte_bus_parse_t parse; /**< Parse a device name */ > + struct rte_bus_conf conf; /**< Bus configuration */ > }; You are making explicit what exists currently: - the PCI bus has a whitelist/blacklist policy - the vdev bus is only a whitelist It is a good step to deinterlace some spaghettis in the code. For the next step, the bus should have no policy. It scans everything. We can have a probing policy, but it should not be stored in the bus. I suggest to add a callback in the probe function which would implement the probing policy: FOREACH_DEV_IN_BUS { if (user_callback(dev, user_data)) probe_one(dev); } For compatibility, rte_eal_init() would call rte_bus_probe() with a default callback which checks the whitelists and blacklists for PCI.