I think a good place to start would be to define what, if any, additional odp_pool attributes need to be added to the odp_pool_params_t struct to capture NUMA considerations. I should also point out that the reason we had map/unmap calls on the buffer/packet API discussions last year was in consideration of NUMA. We may or may not wish to revisit these.
It would also seem that this needs to tie into the thread restructure work that Petri is doing for defining control and worker threads. So lots of angles to explore. On Fri, May 8, 2015 at 7:53 AM, Mike Holmes <mike.hol...@linaro.org> wrote: > > > On 8 May 2015 at 08:14, Bill Fischofer <bill.fischo...@linaro.org> wrote: > >> We should discuss how to approach NUMA considerations in the context of >> ODP APIs as a general design question rather than adding them ad hoc to >> each API as questions arise. >> > > Absolutely. > > Perhaps we should add this to our architecture calls as a topic for the >> next few weeks to see how we can flesh this out? >> > > I agree, if we have some one driving the need, but there is no point > talking theoretically and solving it in the abstract. > I think we have learned that without the drive of someone solving a > problem they have, we never close on the issue. The successful API work has > involved a real problem and a header file proposal to focus the discussion. > > >> We may also have time to expand on this as part of the June Sprint. >> > > Agree, but again we need some thing to anchor the discussion. A sprints > purpose is to focus on solving specif problems, we can discuss generally in > HOs and on the list I think. > With a proposal that outlines the issues to be solved (not starting a > general discussion) I am in favor of adding it to the agenda. > > >> >> Bill >> >> On Fri, May 8, 2015 at 6:58 AM, Mike Holmes <mike.hol...@linaro.org> >> wrote: >> >>> Gabor >>> >>> If you have a proposal for the API, 1.2 is scheduled for the end of this >>> quarter. It may be sooner if there is sufficient content so that is the >>> soonest it could change. >>> >>> Please propose a header file change in api-next to start the discussion >>> to solve your need. >>> >>> Mike >>> >>> On 8 May 2015 at 03:48, Gábor Sándor Enyedi < >>> gabor.sandor.eny...@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> Thanks. So, is the workaround for now to start the threads, and do all >>>> the memory reservation on the thread? And to call odp_shm_reserve() instead >>>> of simple malloc() calls? Can I use multiple buffer pools, one for each >>>> thread or interface? >>>> BR, >>>> >>>> Gabor >>>> >>>> P.s.: Do you know when will this issue in the API be fixed (e.g. in >>>> next release or whatever)? >>>> >>>> >>>> On 05/08/2015 09:06 AM, Jerin Jacob wrote: >>>> >>>>> On Thu, May 07, 2015 at 05:00:54PM +0100, Zoltan Kiss wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> I'm not aware of any such interface, but others with more knowledge >>>>>> can >>>>>> comment about it. The ODP-DPDK implementation creates buffer pools on >>>>>> the >>>>>> NUMA node where the pool create function were actually called. >>>>>> >>>>> current ODP spec is not NUMA aware. We need to have API to support >>>>> nodes enumeration and >>>>> explicit node parameter to alloc/free resource from specific node like >>>>> odp_shm_reserve_onnode(node, ...) >>>>> and while keeping existing API odp_shm_reserve() allocated on node >>>>> where the current code runs >>>>> >>>>> >>>>> Regards, >>>>>> >>>>>> Zoli >>>>>> >>>>>> On 07/05/15 16:32, Gábor Sándor Enyedi wrote: >>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> I just started to test ODP, trying to write my first application, but >>>>>>> found a problem: if I want to write NUMA aware code, how should I >>>>>>> allocate memory close to a given thread? I mean, I know there is >>>>>>> libnuma, but should I use it? I guess not, but I cannot find memory >>>>>>> allocation functions in ODP. Is there a function similar to >>>>>>> numa_alloc_onnode()? >>>>>>> Thanks, >>>>>>> >>>>>>> Gabor >>>>>>> _______________________________________________ >>>>>>> lng-odp mailing list >>>>>>> lng-odp@lists.linaro.org >>>>>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>>>>> >>>>>> _______________________________________________ >>>>>> lng-odp mailing list >>>>>> lng-odp@lists.linaro.org >>>>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> lng-odp@lists.linaro.org >>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>> >>> >>> >>> -- >>> Mike Holmes >>> Technical Manager - Linaro Networking Group >>> Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM >>> SoCs >>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >> > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
