14/04/2019 16:40, Pavan Nikhilesh Bhagavatula: > Hi Thomas, > > There is no guarantee of primary part number (machine names) uniqueness > between implementors.
I think we don't speak the same language :) By machine name, I mean what we set in RTE_MACHINE, like octeontx2. > If we limit lookups to only machine names through primary part number we > would have a lot of repetitive defines. > Also, moving the arrays into the python script is not feasible as meson needs > to reparse the standard out from the python script I will probably need to write a PoC. > Currently, config is split into three parts : > 1. Implementor specific defines. > 2. Micro-arch specific compiler flags. > 3. Micro-arch specific defines. This is currently unreadable in my opinion. > I think from a configurability point of view the above three are really > important for fine grained control. I agree fine grain is required. > Thoughts? > > Regards, > Pavan. > > >-----Original Message----- > >From: Thomas Monjalon <tho...@monjalon.net> > >Sent: Sunday, April 14, 2019 2:13 AM > >To: Jerin Jacob Kollanukkaran <jer...@marvell.com> > >Cc: Pavan Nikhilesh Bhagavatula <pbhagavat...@marvell.com>; > >dev@dpdk.org; jerinjac...@gmail.com; ys...@mellanox.com; > >bruce.richard...@intel.com > >Subject: Re: [dpdk-dev] [PATCH v8 2/4] meson: add infra to support machine > >specific flags > > > >13/04/2019 08:24, Jerin Jacob Kollanukkaran: > >> > I was not confortable with this patch without being able to say why. > >> > Yesterday I spent more time to understand and see what may be improved. > >> > I agree it is late, so it won't block this patch for 19.05. > >> > Do you agree this file can be improved? > >> > >> Moving to the all to static config file is an option but we lose the > >> flexibility of runtime detecting the options and few of them are > >> probing at runtime based on gcc versions and mcpu combination etc. > > > >I think there is a misunderstanding. > >I'm suggesting to symplify arrays by indexing only by machine name. > >It should not change the behaviour. > > > >> I am not expert in meson area and not sure meson/python has better > >> data strcture for this other than list/array combo. If Bruce has any > >> feedback on this, then we will try to prototype it. > >> > >> > Please would you like to look at reworking during next cycle? > >> > Thanks > > > > > >
