Hi Dave, Thanks a lot for the kind help. I was able to resolve the problem. The issue appeared to occur due to incorrect interface name value set to "mhash_set_mem" . When tried to get the interface using mhash_get incorrect value was returned and "pool_elt_at_index" failed to get correct value.
Sorry I had an additional small doubt related to configuring VPP to test multi-threading support in debug mode. I am building the package using "make build" and running using "make run".I have configured the vpp startup.conf to enable "workers"(value set to 2 have two core CPU). I had a confusion is it possible to test this way in debug mode as startup file may not be used. Thanks & Regards, Sreejith On 7 February 2017 at 22:37, Dave Barach (dbarach) <dbar...@cisco.com> wrote: > If you continue to have trouble, please push a draft patch and I’ll take a > look... > > > > Thanks… Dave > > > > *From:* Sreejith Surendran Nair [mailto:sreejith.surendrann...@linaro.org] > > *Sent:* Tuesday, February 7, 2017 11:24 AM > *To:* Dave Barach (dbarach) <dbar...@cisco.com> > *Cc:* vpp-dev <vpp-dev@lists.fd.io> > *Subject:* Re: [vpp-dev] Query regarding VPP Pool allocation > > > > Hi Dave, > > Thanks a lot for your kind help and the valuable inputs. Appreciate the > same. > I will recheck my changes and identify the problem. > > Thanks & Regards, > > Sreejith > > > > On 7 February 2017 at 18:44, Dave Barach (dbarach) <dbar...@cisco.com> > wrote: > > There’s no need to call pool_alloc(...) in typical cases. Pools are > vectors (dynamic arrays), they expand as necessary. > > > > During initial development, please always run TAG=vpp_debug or equivalent > images. If you make mistakes with vector-based data structure(s), the code > tends to ASSERT(...) immediately. > > > > There are a ton of pool-based examples. It’s really no more complicated > than: > > > > typedef struct { > > foo_t * foo_pool; > > } my_main_t; > > > > my_main_t my_main; > > > > > > foo_t *object; > > my_main_t *mp = &my_main; > > > > pool_get (mp->foo_pool, object); > > memset(object, 0, sizeof(*object)); > > > > object_index = object - mp->foo_pool; /* invariant forever */ > > > > /* recover object by index, safe across pool expansion */ > > object = pool_elt_at_index (mp->foo_pool, object_index); > > > > /* Free the object */ > > pool_put (mp->foo_pool, object); > > or > > pool_put_index (mp->foo_pool, object_index); > > > > Notes include: *never* memorize pointers to objects allocated in this > manner, unless you enjoy debugging dangling reference bugs. *Always* > memorize pool indices instead... > > > > Thanks… Dave > > > > *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On > Behalf Of *Sreejith Surendran Nair > *Sent:* Tuesday, February 7, 2017 7:19 AM > *To:* vpp-dev <vpp-dev@lists.fd.io> > *Subject:* [vpp-dev] Query regarding VPP Pool allocation > > > > Hi All, > > > > I am working on VPP/ODP Integration. I had query regarding "pool_get" API. > > I am using call "pool_get(om->interfaces,oif) " with parameters > "om->interfaces" and "oif" should we need to allocate memory for > "om->interfaces" using "pool_alloc" before calling pool_get. > > > > > > I am presently not using "pool_alloc" to allocate memory and using" > pool_get" during interface creation and "pool_put" during interface > deletion. I followed "af_packet/netmap" as reference implementation, > > > > But when I tried to delete the interface I saw "pool_put" call is getting > stuck as the next statements are not executed. I thought it may be because > "pool_alloc" was not used for "om->interfaces".Also while creating multiple > interface and deleting the same I am getting a crash due to pool not free > error. > > > > If possible kindly request if anyone could please correct me. > > > > Thanks & Regards, > > Sreejith > > > > > > > > > > > > > > > > > > > > >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
