From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by dpdk.org (Postfix) with ESMTP id C790E1396 for ; Thu, 7 May 2015 13:06:02 +0200 (CEST) Received: by oiko83 with SMTP id o83so30393919oik.1 for ; Thu, 07 May 2015 04:06:02 -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=Xq3sC//sM1D2Fxo5VRrE+nrcvR11v3pM+MIdQVm3DA4=; b=IilB+OuPeKELjOH9fHGtkxErq4XtodwAf7/7gAsiZw5b674LHf2+tvvDnrBWwdvNOl Qv6YltF3Mrymi/QDZxeZUHQVbVn5uL2dPxc88x+7npf3bVDQS3Di0TBB1cgDSgDkQez1 3dQ8wdgS7rE0uC0+ehg1IQGf49mQLCTKtWEcmlGL6gTML0xKyg5xyIvKLQb8LAKvjEWe zP8fkAoqAyIjgYzjbnFSeHgq45bgDvwWGl13MsAEa9JVFEvxzpnv1MTOBCWcIdr9op4t weT4YRWXaIG+Buu4qZwWMlnrsQ4TP7DL7DZzZedYcTQEgAWIaFtzAmIKDXbHIG2JQeBx SGog== X-Gm-Message-State: ALoCoQkNnKH1Yrllf7D/0pXCHJAzqwtWeQ6ybQro5ts/gbEUUjNlOvXSViPhZUW7uMNvIiz/Do3Y MIME-Version: 1.0 X-Received: by 10.202.187.9 with SMTP id l9mr2608228oif.46.1430996762268; Thu, 07 May 2015 04:06:02 -0700 (PDT) Received: by 10.76.131.19 with HTTP; Thu, 7 May 2015 04:06:02 -0700 (PDT) In-Reply-To: <20150131183535.GA24821@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> <20150131163227.GA23878@localhost.localdomain> <20150131183535.GA24821@localhost.localdomain> Date: Thu, 7 May 2015 13:06:02 +0200 Message-ID: From: David Marchand To: Neil Horman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 11:06:03 -0000 Hello Neil, Reviving this old thread. On Sat, Jan 31, 2015 at 7:35 PM, Neil Horman wrote: > On Sat, Jan 31, 2015 at 05:55:07PM +0100, David Marchand wrote: > > On Sat, Jan 31, 2015 at 5:32 PM, Neil Horman > 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 t= he > > > 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. > > > Yes, absolutely, but it needs to be done in a way that an external binary > can > inspect the object independently of its being loaded, and preferably in a > non-programatic context (since the uio bind/unbind utilities are separate > scripts). > > The modinfo method involves putting info into a special data section that > gets > processed as part of the kernel modpost build stage. There, the addition= al > section gets translated into a C file, and built into its own object that= s > attached to the final binary module. We can so the same thing here if yo= u > like > > We could do something simpler, too. For instance we could add a field to > the > struct that gets registered as part of the RTE_REGISTER_PMD macro, and > export it > via a new ethdev library call. That would be very straightforward, but t= he > implication there is that you would need a programatic method to > interrogate > that information (a binary to call into the dpdk), which is not part of > how the > bind/unbind scripts work today. > > > Thinking aloud ... > > As long as the pmd does all the magic bindings, the dpdk core does not > need > > to know about it. > Yes, I'm not suggesting anything other than the pmd be responsible for > codifying > its binding information. Its how that information is exported to other > utilities that potentially increases the complexity of this operation. > > > 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. > Sure, I don't see a problem with that. If we properly macro-wrap this, we > can > likely add a dynamic registration mechanism without having to change the > pmds > later > Did you work on this ? I have been playing with this, I will most likely propose patches soon. My preferred approach is to dedicate an elf section for this ("=C3=A0 la" k= ernel .modinfo). I tried to reuse modinfo, but the problem is that kmod implementation is checking the filename extension against .ko and .ko.gz. I find it a bit too bad to have to rewrite this kind of tool just for dpdk ... but on the other hand we would need something for bsd as well or we give a shell script that rely on readelf to retrieve theis section. --=20 David Marchand