From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by dpdk.org (Postfix) with ESMTP id 666A48D96 for ; Mon, 18 Jan 2016 22:12:16 +0100 (CET) Received: by mail-ob0-f173.google.com with SMTP id is5so171349922obc.0 for ; Mon, 18 Jan 2016 13:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hbsAwHNtEJnzOoPWkbg5H3rXZQoRHDuRIEdjuCbK+uQ=; b=tZwaJ4j1lBDCFjuiovBMeW6NZo2eDnmshUToNfvmwNoZ1FyfdQaMMp1p3fX4zgve2B bXORIzcmFI4x9aGeaJ1aJKkgaJqW8Wp2NJpguec/SKhnDeW2XPOvYS1JEAlCy4LbfHlq KSgjDQdonnhpd/2agrstxp35su5R+8yrvZFdvbajahS2gKfVJ3GcSP3bdsQ6H5jLHupE 9GAgNmf+UDTBJMwsZphJgWODn8QK293Qml6+seL/VRo0kyg0gNx9JJnMpvkXZTEfjClW hRMP1bwXBQrCBhyBgOi2e8x29ZHkM2KedulSR7gXiTXMS9QEauRYpd6CWP03sDfP4eZv V8mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hbsAwHNtEJnzOoPWkbg5H3rXZQoRHDuRIEdjuCbK+uQ=; b=NLDYmTHbI/lRczO4AZH31G2Xp3QgwqvILJEWxPBPAFcYNpuHQRtU+p/xiJMXz4Rk4V 4nWRCSnJd/7QfQqk8BbOlCFs3ELk0U4ZTKKTgk3c5uXnXwuV7lKPlm8ciRfFzZ8qup8u FOeqxLBnvq/mLlXwCFDH5A2q8JznDnFz1u+rRepdIJhIk3OjstTHPn9HjRPXzQoc5k6A 54N/+m/6gcudKk6mNz7adpArwSx7glU4AaJtaJlMAriuHT+1L1uH2eIyjK4U5oqSME0u f0MDAyBOGBKtk6AOwcjOzajeA3SX/ri0ZRcNy4hGvc8gDEBtu2qxPNG5eEkaRHlnuj0P Vpyg== X-Gm-Message-State: ALoCoQk2y4ZqMiArbWvdq2YIuYmLJfxCbhm3WYAAfevQWexLDLsecR/YjqHJ0EjAPbjyP2zjsILk4U358AChfBu7cqiK2FsSQZ1OVGRh6wPZ0RySmfNAgKY= X-Received: by 10.182.131.202 with SMTP id oo10mr21575280obb.72.1453151535728; Mon, 18 Jan 2016 13:12:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.180.72 with HTTP; Mon, 18 Jan 2016 13:11:56 -0800 (PST) In-Reply-To: <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz> References: <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz> From: David Marchand Date: Mon, 18 Jan 2016 22:11:56 +0100 Message-ID: To: Jan Viktorin Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup 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, 18 Jan 2016 21:12:17 -0000 Jan, I was waiting for some others feedbacks before going into the code. Glad to see you already tried this. On Mon, Jan 18, 2016 at 3:58 PM, Jan Viktorin wrote: > On Thu, 14 Jan 2016 11:38:16 +0100 > David Marchand wrote: >> - no need for a rte_pci_driver reference in rte_pci_device, since we >> have the rte_device driver > > This is an issue, see below. > >> >> - rte_pci_driver is modified to embed a rte_driver > > The rte_driver and rte_pci_driver are related in a much different way > at the moment. The meaning of rte_driver is more like an rte_module in > the current DPDK. > > In fact, we don't have any generic rte_driver suitable for this purpose. > Thus, the transition to this model needs to rename rte_driver to > rte_module and to introduce a new data structure named rte_driver. > > Quite confusing... but this is how I understand it. Hum, yes. Well, looking at current rte_driver, this code has been first thought as a way to load pmd through dso, so yes, this is more like module init. Then the hotplug has been hooked on this, adding to the confusion. > (What is the current relation between rte_pci_device and rte_pci_driver? > Is the rte_pci_driver a singleton? I doubt. Well, it cannot be, as it > is embedded in each eth_driver.) Not sure I understand the question. At the moment, a rte_pci_device references a rte_pci_driver. Associating those happens at pci "probe" time lib/librte_eal/common/eal_common_pci.c +202 I agree there is a pci_driver embedded in eth_driver, but that does not mean pci drivers must be eth drivers. > Another way, not that beautiful... Introduce rte_generic_driver and > rte_generic_device. (Or rte_gen_driver/rte_gen_device or > rte_bus_driver/rte_bus_device if you want). This enables to let the > rte_driver as it is and it avoids a lot of quite terrible transition > patches that can break everything. > >> - no more devinit and devuninit functions in rte_pci_driver, they can >> be moved as init / uninit functions in rte_driver > > The rte_driver has init/uninit already and its semantics seem to be > module_init and module_uninit. Ok, so what you propose is something like this ? - keep rte_driver as it is (init and uninit), I would say the name can be changed later. - add rte_bus_driver (idem, not sure it is a good name) in place of the rte_driver I mentioned in my initial mail. Rather than have init / uninit, how about attach / detach methods ? Regards, -- David Marchand