Please note that we also have fixed pool implementation which may be used if you want to prevent pool resizing…..
Another option is to make your entries cacheline aligned, and then convert pointer to heap offset shifted right for LOG2_CACHELINE_SIZE. That will give you working solution for HEAP sizes up to 256G. We do something similar in the buffer allocator. — Damjan > On 20.01.2021., at 16:26, hemant via lists.fd.io > <hemant=mnkcg....@lists.fd.io> wrote: > > Hi Ben, > > Great, thanks for the pool info! I am all set. I will close the JIRA issue > and also the code review. > > Best wishes, > > Hemant > > -----Original Message----- > From: Benoit Ganne (bganne) <bga...@cisco.com <mailto:bga...@cisco.com>> > Sent: Wednesday, January 20, 2021 9:47 AM > To: hem...@mnkcg.com <mailto:hem...@mnkcg.com>; ne...@graphiant.com > <mailto:ne...@graphiant.com>; ayour...@gmail.com <mailto:ayour...@gmail.com> > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > Subject: RE: [vpp-dev] classifier howto? > >> No, a u64 suffices. See how the u64 works with a bihash for any value, >> not just pkt_filter4_0_value, in the code example given below. > > Ok thanks. So you use the u64 to store a pointer to your structure allocated > on the heap. > The usual way to do this in VPP instead is to allocate your structure in a > pool. You can then store the u32 index of your data in the bihash and use > opaque_index directly. > > value = pool_get(pkt_filter4_pool); > u32 index = value - pkt_filter4_pool; > memcpy(value, &val, sizeof(val)); > kv.value = index; > clib_bihash_add_del_48_8 (&ump->hash_table_pkt_filter4_0, &kv, 1); > > Then you can retrieve value using this index (either coming from bihash > lookup > or from opaque_index): > value = pool_elt_at_index(pkt_filter4_pool, index); > > I am not convinced adding metadata in opaque or opaque2 is really needed here. > > Best > ben > >> struct pkt_filter4_0_value val = {}, *value; >> >> val.action = permit4; >> >> val.u.permit4.abits = 130; >> >> val.u.permit4.ig_strip = 0; >> >> val.u.permit4.outer_desc = 1; >> >> val.u.permit4.teid = 5241; >> >> val.u.permit4.ip = 0x03030302; >> >> val.u.permit4.src_ip = 0x03030301; >> >> val.u.permit4.dstPort = 2152; >> >> val.u.permit4.filt_dir = 1; >> >> val.u.permit4.reflec_qos = 0; >> >> >> >> value = malloc(sizeof(val)); >> >> memcpy(value, &val, sizeof(val)); >> >> kv.value = (u64) value; >> >> clib_bihash_add_del_48_8 (&ump->hash_table_pkt_filter4_0, &kv, 1); >> >> >> >> Hemant >> >> >> >> -----Original Message----- >> From: Benoit Ganne (bganne) <bga...@cisco.com> >> Sent: Wednesday, January 20, 2021 8:13 AM >> To: hem...@mnkcg.com; ne...@graphiant.com; ayour...@gmail.com >> Cc: vpp-dev@lists.fd.io >> Subject: RE: [vpp-dev] classifier howto? >> >> >> >>> A github link is included in the JIRA issue to articulate the use >>> case, >> >>> https://jira.fd.io/browse/VPP-1967 >>> <https://jira.fd.io/browse/VPP-1967> >> >>> The github link has a value for a classifier entry shown: >> >>> https://github.com/FDio/vpp/pull/33 >> <https://github.com/FDio/vpp/pull/33> >> >>> The value is a value used in a 5G UPF. >> >> >> >> Is the 64-bits value you refer to the "struct pkt_filter4_0_value"? It >> looks much bigger than 64-bits to me... >> >> >> >> Best >> >> ben > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18571): https://lists.fd.io/g/vpp-dev/message/18571 Mute This Topic: https://lists.fd.io/mt/79925983/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
