If we think of the context of ODP applications in the field, not on developer machines:
The system will be dimensioned to support whatever memory is required for the different components, including ODP. So it is just about doing the proper reservations, not asking what is available. the odp_shm_reserve may come with additional attributes for DMA or other stuff. If it fails, ODP fails. So the API should be about reservation, not getting information. Specific LOG messages about lack of available memory may include information about that, but those are implementation dependent. FF On 23 October 2017 at 22:01, Bill Fischofer <bill.fischo...@linaro.org> wrote: > On Mon, Oct 23, 2017 at 2:22 PM, Maxim Uvarov <maxim.uva...@linaro.org> > wrote: > > > On 10/23/17 18:23, Francois Ozog wrote: > > > Hi Maxim, > > > > > > Is this regular memory or DMA capable memory? > > > > > > This would mean application would know how, for instance, to handle > > things > > > when memory is lower than a threshold or something similar; or it may > > > decide to use a percentage of memory for packet pools; or many other > > > policies. I don't see that feature in "mature" applications like VPP. > > > > > > Applications that want do that may still use platform information > > directly > > > but I think it is too early work on an ODP API for that. An ODP memory > > API > > > will also have to deal with NUMA... > > > > > > FF > > > > > > I came to that question after Petri's api to print ODP shm info. > > > > We have pool capabilities which how many pools with which size can be > > created. DMA memory should connected to pool capabilities info. > > > > I had this discussion with Yi earlier today and we'll be covering it during > tomorrow's ODP 2.0 call. The question of adding additional pool attributes > to cover type of storage, whether it needs to be physically contiguous, > etc. is a reasonable one to explore. Certainly the long-delayed NUMA topic > is relevant here. Petri has indicated he has more ideas to follow in this > area as well. > > > > > > But odp_shm_reserve() (which is also connected to pool resources) does > > not have maximum value for reserve. On some platforms not all system RAM > > can be used as shared memory. So to run apps there you will need to > > specify somewhere amount of available RAM for ODP application. > > > > If query of total/free memory for odp_shm_reserve() is platform specific > > than single binary will not work on different platforms. Or will require > > some start up script to specify this amount. If it will be script than > > it will have bunch of 'if platform' conditions. If we place it inside > > ODP then it will be easy to get this number. > > > > The problem with memory is it's not so simple to come up with a single > number. That's why odp_pool_create() exists and lets the application know > up-front whether it succeeds or fails. If it succeeds, then the application > doesn't have to worry about runtime surprises in not being able to allocate > a buffer/packet, as long as it's maintaining a steady-state of allocates > and frees. Remember, in the data plane the idea is to move packets through > the application rapidly to minimize overall latency. Storing huge numbers > of "pending" packets is contrary to this goal. Hence the number of "in > flight" packets (plus a safety margin) is what determines the needed pool > size, and that's more a function of the number of pktios and their I/O > rates than the available RAM. > > > > > > Maxim. > > > > > > In general we need allocated > > > > > > On 23 October 2017 at 14:26, Bill Fischofer <bill.fischo...@linaro.org > > > > > wrote: > > > > > >> Applications should request the amount of storage they need (possibly > as > > >> configured) rather than trying to grab everything they can find "just > in > > >> case". Especially in an NFV environment that's not very neighborly > > >> behavior. > > >> > > >> On Mon, Oct 23, 2017 at 2:44 AM, Dmitry Eremin-Solenikov < > > >> dmitry.ereminsoleni...@linaro.org> wrote: > > >> > > >>> On 23/10/17 10:39, Maxim Uvarov wrote: > > >>>> It might be reasonable to add also api call to get return free > memory. > > >> So > > >>>> that application can adjust pools /buffers size according to > hardware > > >> or > > >>> VM > > >>>> settings. Which might be good fit for NFV set up. > > >>>> Any opinions on that? > > >>> > > >>> It would depend on the platform too much. Also remember, that in some > > >>> cases buffers/packets will use separate memory, not main RAM. > > >>> > > >>> -- > > >>> With best wishes > > >>> Dmitry > > >>> > > >> > > > > > > > > > > > > > > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
