Ole and Neale,
You have both asked essentially the same question in a code review:
Neale:
what's the use case for these tag fields?
if i's to correlate VPP objects with user-assigned IDs, are there any
object in VPP
that would not require a tag?
Ole:
Would it be possible to come up with a scheme were you didn't allocate the
space
for the tag strings unless they were used by a domain? I have seen use
cases with millions of domains. 64 byte * 2M is still a bit of memory.
Otherwise I'm perfectly fine with the idea though. Although the address to
tag mapping
could happily live outside of VPP too, right?
To summarize, we have effectively added some from of user-assigned ID to
every create-able
object in VPP that we have placed under management. There are basically 3
approaches
we have taken:
1) Add a u32 "user-ID" to the objects's main per-instance structure.
2) Add a string "tag" field to the object's main per-instance structure.
3) Allow the user to supply a "user ID".
If that is supplied and it is available, use it as the instance ID.
If it is not supplied, VPP picks a free one (from pool).
In any case, there is usually still a distinction between the "user ID" and
the "device instance".
Except for case 3), VPP really only stores and regurgitates the user ID (on
create and dump,
respectively). For 3) some more fiddling (in-use bit-vector) is necessary.
An example of case 3) is found in the bridge management code, here:
src/vnet/l2/l2_bd.c
The primary implementation are the functions bd_find_index()
and bd_add_bd_index()
They are used in bd_add_del() and l2bd_init().
I point this out, as I am wondering if you would be willing to use this
approach with
the MAP domain IDs too. They would still be allocated using the same pool,
of course, but this would allow the user to pick a free pool index and thus
use only
one name (ID), and not have to manage two IDs.
If you do not want to take this approach, I am happy to add a hash table
mapping the existing map domain indices to either a user-supplied u32
or string name. (This approach incurs essentially no extra space when
user-supplied names or u32 IDs are not supplied.)
Thanks,
jdl
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12562): https://lists.fd.io/g/vpp-dev/message/12562
Mute This Topic: https://lists.fd.io/mt/30443795/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
