On Thu, Jul 1, 2021 at 6:36 AM Damjan Marion <dmar...@me.com> wrote: > > > > On 01.07.2021., at 11:12, Benoit Ganne (bganne) via lists.fd.io <bganne= > cisco....@lists.fd.io> wrote: > > > >> Yes, allowing dynamic heap growth sounds like it could be better. > >> Alternatively... if memory allocations could fail and something more > >> graceful than VPP exiting could occur, that may also be better. E.g. if > >> I'm adding a route and try to allocate a counter for it and that fails, > it > >> would be better to refuse to add the route than to exit and take the > >> network down. > >> > >> I realize that neither of those options is easy to do btw. I'm just > trying > >> to figure out how to make it easier and more forgiving for users to set > up > >> their configuration without making them learn about various memory > >> parameters. > > > > Understood, but setting a very high default will just make users of > smaller config puzzled too 😊 and I think changing all memory allocation > callsites to check for NULL would be a big paradigm change in VPP. > > That's why I think a dynamically growing heap might be better but I do > not really know what would be the complexity. > > That said, you can probably change the default in your own build and > that should work. > > > > Fully agree wirth Benoit. We should not increase heap size default value. > > Things are actually a bit more complicated. For performance reasons people > should use > hugepages whenever they are available, but they are also not default. > When hugepages are used all pages are immediately backed with physical > memory. > > So different use cases require different heap configurations and end user > needs to tune that. > Same applies for other things like stats segment page size which again may > impact forwarding > performance significantly. > > If messing with startup.conf is too complicated for end user, some nice > configuration script may be helpful. > Or just throwing few startup.confs into extras/startup_configs. > > Dynamic heap is possible, but not straight forward, as at some places we > use offsets > to the start of the heap, so additional allocation cannot be anywhere. > Also it will not help in some cases, i.e. when 1G hugepage is used for > heap, growing up to 2G > will fail if 2nd 1G page is not pre-allocated. > > Sorry for not being clear. I was not advocating any change to defaults in VPP code in gerrit. I was trying to figure out the impact of changing the default value written in startup.conf by the management plane I work on. And also have a conversation on whether there are ways that it could be made easier to tune memory parameters correctly.
-Matt
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19685): https://lists.fd.io/g/vpp-dev/message/19685 Mute This Topic: https://lists.fd.io/mt/83856384/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
