From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [PATCH 04/18] fm10k: add fm10k device id Date: Thu, 7 May 2015 09:36:14 -0400 Message-ID: <20150507133614.GB336@hmsreliant.think-freely.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: David Marchand Return-path: Content-Disposition: inline In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On Thu, May 07, 2015 at 01:06:02PM +0200, David Marchand wrote: > Hello Neil, >=20 > Reviving this old thread. >=20 > On Sat, Jan 31, 2015 at 7:35 PM, Neil Horman wr= ote: >=20 > > 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 l= ike 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 bo= ther > > with > > > > > this ... > > > > > - the pmd handles this automatically (like binding/unbinding on= a > > kernel > > > > > driver), with a _runtime_ option to enable this behavior (defau= lt > > being > > > > "no > > > > > automatic bind") > > > > > > > > > > Comments ? Ideas ? > > > > > > > > > I like the modalias idea, as it transports a table for uio/vfio t= o > > > > identify with > > > > the binary that needs it, preventing a possible discrepancy in wh= at 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. > > > > > Yes, absolutely, but it needs to be done in a way that an external bi= nary > > can > > inspect the object independently of its being loaded, and preferably = in a > > non-programatic context (since the uio bind/unbind utilities are sepa= rate > > 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 addi= tional > > section gets translated into a C file, and built into its own object = thats > > attached to the final binary module. We can so the same thing here i= f you > > like > > > > We could do something simpler, too. For instance we could add a fiel= d to > > the > > struct that gets registered as part of the RTE_REGISTER_PMD macro, an= d > > export it > > via a new ethdev library call. That would be very straightforward, b= ut the > > 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 fo= r > > codifying > > its binding information. Its how that information is exported to oth= er > > 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 sy= stem > > > 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 > > >=20 > Did you work on this ? >=20 No, I had assumed from our previous discussion that you were. >=20 > I have been playing with this, I will most likely propose patches soon. >=20 > My preferred approach is to dedicate an elf section for this ("=E0 la" = kernel > .modinfo). Yes, this makes sense. > I tried to reuse modinfo, but the problem is that kmod implementation i= s > checking the filename extension against .ko and .ko.gz. >=20 Well, you can alter modinfo so that it looks at .so files if you like, bu= t thats not the only tool you can use. Truthfully you can just use objdump if yo= u like. > I find it a bit too bad to have to rewrite this kind of tool just for d= pdk > ... 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 See above, try objdump -j=3D.modinfo -S /path/to/kernel/module. objdump = doesn't care about file extensions, as long as its ELF. With that you can: 1) Dump out any section contents you like 2) strip away the application top end, and just use libbfd to get at the = elf contents if you like. Neil >=20 > --=20 > David Marchand