From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kamil Rytarowski Subject: Re: [PATCH 1/2] ethdev: Allow to overload pci_drv.devinit and pci_drv.devuninit Date: Wed, 3 Feb 2016 16:59:36 +0100 Message-ID: <56B223E8.8060001@caviumnetworks.com> References: <1454423239-16382-1-git-send-email-krytarowski@caviumnetworks.com> <56B1E70B.4070607@caviumnetworks.com> <56B2217C.9030407@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit To: Return-path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0071.outbound.protection.outlook.com [65.55.169.71]) by dpdk.org (Postfix) with ESMTP id E41D2559C for ; Wed, 3 Feb 2016 16:59:49 +0100 (CET) In-Reply-To: <56B2217C.9030407@caviumnetworks.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" W dniu 03.02.2016 o 16:49, Kamil Rytarowski pisze: > > > W dniu 03.02.2016 o 15:08, David Marchand pisze: >> On Wed, Feb 3, 2016 at 12:39 PM, Kamil Rytarowski >> wrote: >>> W dniu 03.02.2016 o 09:47, David Marchand pisze: >>>> And do your custom things in its devinit function ? >>> I'm requesting from PF the mode of the device to be initialized. >>> This part >>> is handled dynamically and depends of the current configuration in PF. >>> >>> In my use-case there are two device types: primary (master) and >>> secondary >>> (slave). For the primary VF I'm creating a DPDK port normally, for >>> secondary >>> I retain configured PCI device for further reuse (and there is no port >>> created). >> Well, again, if you don't want to associate a port to this pci >> resource, why are you registering a eth_driver ? >> A eth_driver driver supposes you have a 1 - 1 relation between ethdev >> and pci resource. > In my use-case one DPDK port optionally manages more than single PCI > resource, and these PCI resources compose single interface. > > Another example of overloaded .devinit is in app/test/test_pci.c: > > /* > * PCI test > * ======== > * > * - Register a driver with a ``devinit()`` function. > * > * - Dump all PCI devices. > * > * - Check that the ``devinit()`` function is called at least once. > */ > > With the current implementation it won't work, as .devinit callback > will be overwritten by the internal function. > >> For your case, register a pci driver, then in your pci probing >> function (.devinit), depending on what you want to do, you can either >> do nothing (?) or create one or more ethdevs (see mlx* and cxgbe >> drivers). >> >> >> > > This is what I'm doing right now. > > I need to initialize PCI bars and interrupts (resources) - all having > the same PCI ID and their functionality depending upon PF > configuration. Depending on this state, I'm making further decisions > in DRIVER_devinit() and whether to make from it a port or a resource > to reuse by a master port. After sending the mail I noted that I can work with the .init callback and I may be wrong. I will have a closer look and I will check whether it will work for me. Thank you,