From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 15E8C1C00 for ; Mon, 4 Dec 2017 10:32:02 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5DDAC20C4F; Mon, 4 Dec 2017 04:32:00 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 04 Dec 2017 04:32:00 -0500 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; s=mesmtp; bh=iMDWpDKi10i7P7kbxoPNlRNNzh l9cbMSqRcKTkjLpMY=; b=O4lodzeF+zsjnHvDNgWN9DLGRvO70NVwVrJ4n3uB4y uHJ3y8qsTbFXhlX7i3wr5ELeLpcmEz+NVpwsVyqxko5yBWk6ilqLstD45LS7GUiD UCoWm58ii6kck6jPsbz20BCFj148Poq5J81iCaJAKwcL2wRwtlp+B3crv8Y5b6Os Y= 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; s=fm1; bh=iMDWpD Ki10i7P7kbxoPNlRNNzhl9cbMSqRcKTkjLpMY=; b=rMd/Dmrs+2QB7OSS9k+uQs cur/osurE7OIflJbKWNbLhvyPTHWNsQVfhqaITf06ACkfcq0yX11WPVBhgCllSTy uNTOhEVpM89wWsBiMmAjqV8oNP/JcYZdXP3Vs8xQRpsNcUiG/OhcLfssPUBiboO8 juTeUIl3g61UkGnYe4Vo00IAG9PH0JI8dLHxSQ30qgcP5Khxjr6LYxhQBuk4Aqf2 6eWz0PPR7q6DbvC6MuZQJxUjbxjBOxfx4l5rBN9RdmTEp1hikm+vPA7sYTR4aBab cYwwU2BeYwDQO85Y3xIvg+NHDHoHcZEiK2cvXA0312IkHmX/XZbmbp058t7NQ1MQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id F34D27E6B8; Mon, 4 Dec 2017 04:31:59 -0500 (EST) From: Thomas Monjalon To: "Tan, Jianfeng" Cc: dev@dpdk.org Date: Mon, 04 Dec 2017 10:31:58 +0100 Message-ID: <2579199.neyJOE5Nyd@xps> In-Reply-To: References: <20171201003642.19827-1-thomas@monjalon.net> <1811632.lxrxycaykj@xps> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] bus/vdev: add custom scan hook 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: Mon, 04 Dec 2017 09:32:02 -0000 04/12/2017 09:08, Tan, Jianfeng: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > Hi, > > > > 01/12/2017 06:48, Tan, Jianfeng: > > > Hi Thomas, > > > > > > Please help us to understand why we need this. > > > > > > > > > On 12/1/2017 8:36 AM, Thomas Monjalon wrote: > > > > The scan callback allows to spawn a vdev automatically > > > > given some custom scan rules. > > > > > > These two new APIs (rte_vdev_add_custom_scan and > > > rte_vdev_remove_custom_scan) are called by applications? > > > > Yes, the application can use it but it can also be used by a DPDK > > driver or library. > > > > > If so, why not just constructing them in the parameters before passing > > > to rte_eal_init? > > > > It is not only for initialization because it will also work when > > we will have some hotplug mechanism where the scan is run during run-time. > > > > > > It is especially useful to create a TAP device automatically > > > > connected to a netdevice as remote. > > > > > > It sounds like an use case. Without this patch, I suppose we can already > > > do this? > > > > Yes we can already update the devargs list. > > But this hook will help to do it on hotplug events. > > Do you mean, we will have the udev monitoring framework, and after monitoring the uevent (hotplug), we want to automatically add a vdev (tap) for that detected physical device which is managed by kernel? Yes, we get the hotplug event first. Then the kernel may manage it. And at last, the DPDK hook decide to connect a vdev to it. Note that it would work for other vdevs like af_packet or pcap. > Considering the scan hook is added in bus->parse(), how this can happen automatically? The hook is in bus->scan(). I think we should launch a bus scan when there is a new device event.