From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by dpdk.org (Postfix) with ESMTP id 6A30CC31E for ; Fri, 8 Jan 2016 14:20:51 +0100 (CET) Received: by mail-ob0-f176.google.com with SMTP id xn1so79537653obc.2 for ; Fri, 08 Jan 2016 05:20:51 -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:date:message-id:subject:from:to :cc:content-type; bh=42ELwJjIC16GFIWoqG1zuY0x+Hpweg27I48kWGBqlLI=; b=p2gdCml2ncTubXLvFDUXx1gJcIStyx8VuxNmw+EmHDhSNb7Mq1aJ5pygP4e7HqtAf2 3xZRuyFAnRI5MN+0D8Fu/9f89Ods6utnN/K1SfR4PL+Fl8QLIoztdIZB/4O4RzQ7rT4t 8qNHSeTo2kjHRGyyJwsxN8v0Unq88KAasPawQzvMrq93ZiIFt3jP8ascpkZ+fjrGB91D g74duF8A+dDAcWKYX3juy/KCJGy1u3EjB3NDZSaPbmFnyIo4fw7T4Dekek5ZkPxhX0xH ChHdgd3dqHgSfu61+HJlvIcbsB1dApyWs7iWPHedZFia7FTP7MHaflMKIueyLaTPcUk3 mCZA== 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:date :message-id:subject:from:to:cc:content-type; bh=42ELwJjIC16GFIWoqG1zuY0x+Hpweg27I48kWGBqlLI=; b=GrhHgtClX1LCe0E0RwTSa0v5c4tr54NRhBd0+2T+5v/qWySAfZOaugiyZnZI9+z11i bbrSvHv0XEbpJyvg69AMsmzou2W7Et0ihaIQYaQ0z6wt2E3CygYJK/0/3Vfn9HEy6wlr 0Re6hCrLoTkUZ8fnJGOmKFQkL95Nj12bNaJSCcnRfCQ0NIyl5OHJeESJs/gExKGC+g+d pJWfq7EmCfeLydUJbfQK5DRvyHlvQtOfh3SosDRhtBdQ7E5+pg06FuDRbqTfU1IOVtaP E26/0VMK/DcUL0z1VGeEg4r+MnP+xl7TFkomU1v+4q0zklTVvkDN1jNE5QOqXCFcb3NJ I4Lw== X-Gm-Message-State: ALoCoQnuWk748TjU8X9NqwbFdLCbmhQAXv19XtNi+/6LlNk/OB6Gok3MCjYMG+j2Vn7/EOqIvvx+f8FtW4iHaZZsQbDfxJi4THWgErplDfE0Q9Iaa49hnks= MIME-Version: 1.0 X-Received: by 10.60.82.101 with SMTP id h5mr78897531oey.44.1452259250738; Fri, 08 Jan 2016 05:20:50 -0800 (PST) Received: by 10.76.180.72 with HTTP; Fri, 8 Jan 2016 05:20:50 -0800 (PST) In-Reply-To: <5405012.WIUT4XHNxg@xps13> References: <20160105113723.6d2b85e5@xeon-e3> <5405012.WIUT4XHNxg@xps13> Date: Fri, 8 Jan 2016 14:20:50 +0100 Message-ID: From: David Marchand To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] time to kill rte_pci_dev_ids.h 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: Fri, 08 Jan 2016 13:20:51 -0000 Hello, On Wed, Jan 6, 2016 at 2:40 AM, Thomas Monjalon wrote: > 2016-01-05 11:37, Stephen Hemminger: > > Has anyone looked at getting rid of rte_pci_dev_ids.h? > > The current method with #ifdef's and putting all devices in one file > > really doesn't scale well. Something more like other OS's where > > the data is only in each device driver would be better. > > I agree. > The PCI ids should be embedded in drivers. > If I remember well, it's already the case for some of them. > I would love to see a tool able to list the supported devices > by reading a binary libraries. > I have done the first part of the job, moving all pci dev ids to the pmds, just rebased it. I can post this. In the last patch of the series, I put all those ids in a dedicated section, that can be dumped with objdump. Having a tool for this (like what I proposed some time ago) would be great but I did not find time to write it. The thing is, what do we want to achieve with such a tool ? My usecase at the moment is for "automatic" device binding to kernel drivers before starting dpdk or when hotplugging. But for this, I think that introducing a hook system in the pci probe functions is better. I am thinking of a hook system that would execute an external tool (shell scripts, C, ...) with all needed informations: pci device, pmd that wants it, driver flags etc... Return value would tell eal what to do next. This would make it possible to implement the blacklist / whitelist out of eal itself, implement auto bind and maybe more. If I go this way, I don't think that we need to expose the pci dev ids :-) -- David Marchand