From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by dpdk.org (Postfix) with ESMTP id 8CE316893 for ; Mon, 29 Sep 2014 04:59:51 +0200 (CEST) Received: by mail-lb0-f172.google.com with SMTP id b6so1640627lbj.3 for ; Sun, 28 Sep 2014 20:06:25 -0700 (PDT) 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=/zVnY4np4Uh+GeyasFhkrH4aKTkKRZIPfteeSK12b/g=; b=eBohRziKrTpKXVuiQzK5ruC4TxGHGegjAltqrKPxagatAdakC/YyU5mIGn3h7zfhoG pDGGqgrKpAcIma3lgDKxD4HMqWffPwXXyebvOxOV4vuBU7G+zKgLri5+S6z1QoaJbeAQ 1KsQ8TDd0oG2o+kJxA/K6o0aFjNkfJRZkJgQuVosFl2lErs43QOLXScG4r8voyUJJKql RcEk436479ZYjyT1LYvU4Rg70b7h+WFldNUbrL/I4VaMWYO6S29ZvUp8D5jj1YwLljvC HQkFxTZuuoLxPO8ftjl8Nm3fUS6fMngc14LJlx+ihT0URjS8VIzVqiTljihad7LPfPkf BysA== X-Gm-Message-State: ALoCoQmgSeY7amU/XBQ5HoF8aOf1ktyPcTN1lQGqKgC53P91saPDT+0X07K0hPkXtRcdI+ubtK2v MIME-Version: 1.0 X-Received: by 10.152.10.203 with SMTP id k11mr36850104lab.30.1411959985279; Sun, 28 Sep 2014 20:06:25 -0700 (PDT) Received: by 10.25.205.1 with HTTP; Sun, 28 Sep 2014 20:06:25 -0700 (PDT) In-Reply-To: <20140928123640.GC30445@localhost.localdomain> References: <1411874836-3274-1-git-send-email-hengx.ding@intel.com> <20140928123640.GC30445@localhost.localdomain> Date: Sun, 28 Sep 2014 20:06:25 -0700 Message-ID: From: Stephen Hemminger To: Neil Horman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] ethdev: The users could get device types now 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, 29 Sep 2014 02:59:51 -0000 Agree with NACK. This type of string matching won't scale. THe better way is to encapsulate required behavior in feature flags. I started that with drv_flags, and that seems natural home for such device specific stuff. On Sun, Sep 28, 2014 at 5:36 AM, Neil Horman wrote: > On Sun, Sep 28, 2014 at 11:27:16AM +0800, Ding Heng wrote: > > As different PMDs support different features, application may want > > to know the NIC type of a port, then decide how to use that port. > > Add a new field in struct rte_eth_dev, users are able to get > > device type now. > > > > Signed-off-by: Ding Heng > Nack. This patch embodies PMD specific information in a common library, > which > really isn't necessecary. It implies that developers who maintain PMDs > outside > of the core dpdk still need to do some maintenence in the core for all the > dpdk > features to work. Its also a layering violation. The core shouldn't > have to > know any specifics about a driver to initalize it, even its name. > > If an application wants to know what type of driver a NIC is, > the application can just interrogate the pci drivers name field directly. > > Neil > >