From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <david.marchand@6wind.com>
Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com
 [209.85.214.175]) by dpdk.org (Postfix) with ESMTP id D60EE5A81
 for <dev@dpdk.org>; Sat, 31 Jan 2015 17:55:07 +0100 (CET)
Received: by mail-ob0-f175.google.com with SMTP id wp4so28634683obc.6
 for <dev@dpdk.org>; Sat, 31 Jan 2015 08:55:07 -0800 (PST)
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=JThku/oPZlszMqdTruh2EHNA8fJ2QnEjGOwte9qP1G0=;
 b=B75vVSNBh6BC0mbyI3dghDKsNPpsrLhdedS/pv2xF8eEquafyQYaR7iiGCQ9zKLQX7
 LN6hZcsgzw47uOaDchKghyPDSpozwtt+lcPo/c6tiPiZx6WUOWhb081NrxgwYPSN9JJj
 jWLgSUdXWYzzhhz+gJWvg2S2CYLxMBxLBxNsOyuU9M3heBQ5eRHi4bL2yOdcyyoBIw4V
 sZtfvmJd/1iQ/XnODtzWmg4djcPbFEm7j02a7iEdDy/icxgVERxuSPCy925Len0dRK58
 oqN3eY47m4BTqyHk/yAvMROjLjJR63sO/JfFHqvaycgCc0dAA+LlOeJODTXU7TbB01/e
 CeCw==
X-Gm-Message-State: ALoCoQmEtma8c4M/gbaMVRe3UPcqa8bb1/uxgdWp1Pj2TYsofogPLwdPGR9B0FDRMLMsUydMeKfc
MIME-Version: 1.0
X-Received: by 10.60.54.71 with SMTP id h7mr7312850oep.56.1422723307151; Sat,
 31 Jan 2015 08:55:07 -0800 (PST)
Received: by 10.76.95.198 with HTTP; Sat, 31 Jan 2015 08:55:07 -0800 (PST)
In-Reply-To: <20150131163227.GA23878@localhost.localdomain>
References: <1422594454-11045-1-git-send-email-jing.d.chen@intel.com>
 <1422594454-11045-5-git-send-email-jing.d.chen@intel.com>
 <20150131141935.GB22012@localhost.localdomain>
 <CALwxeUsVNxZ4-dGSr-oyL2BdPjvgKgF0Yn9N1kBUreC6RBfXcg@mail.gmail.com>
 <20150131163227.GA23878@localhost.localdomain>
Date: Sat, 31 Jan 2015 17:55:07 +0100
Message-ID: <CALwxeUtkfPnh9aAzoL-t6r65nhcqnH7_oC8KMjMf8Ao_+QizKg@mail.gmail.com>
From: David Marchand <david.marchand@6wind.com>
To: Neil Horman <nhorman@tuxdriver.com>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 04/18] fm10k: add fm10k device id
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Jan 2015 16:55:08 -0000

On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman <nhorman@tuxdriver.com> wrote:

> On Sat, Jan 31, 2015 at 05:07:28PM +0100, David Marchand wrote:
> > In the end, we miss something to have dpdk work automatically like it
> used
> > to be, before the pci devices ids were stripped out of igb_uio.
> >
> > I can see two solutions :
> > - all pmds export the pci device ids they support (this sounds like
> > modalias :-)) or they register into the eal that exports this information
> > for use by application, but to me the application should not bother with
> > this ...
> > - the pmd handles this automatically (like binding/unbinding on a kernel
> > driver), with a _runtime_ option to enable this behavior (default being
> "no
> > automatic bind")
> >
> > Comments ? Ideas ?
> >
> I like the modalias idea, as it transports a table for uio/vfio to
> identify with
> the binary that needs it, preventing a possible discrepancy in what the
> core
> dpdk library identifies as supported devices and what the pmd DSO's
> actually do
> support.
>

Yes, but if a pmd can do this itself alone, there is no discrepancy either.

Thinking aloud ...
As long as the pmd does all the magic bindings, the dpdk core does not need
to know about it.
And if the dpdk core really needs to know about this (I can see no use case
here, just want to avoid being blocked later) a dynamic register system
would be fine too.



> To implement it we would either provide our own linker script or have to
> do some
> other make trickery.  The linker script is a bit more labor intensive, but
> might
> provide some future benefit (if you see a need for non-standard sections
> that
> you would like to suck into a given DSO in the future).  Make trickery
> would be
> more straightforward, but requires that we add some additional make
> targets to
> build out the dynamic table to be readable by outside utilities.  Maybe we
> could
> use objcopy to add in a separate section after the dso link.  Not sure yet
>

Not sure either, I just think we may reinvent the wheel :-)


-- 
David Marchand