Hi Chris, That is probably going to be helpful at scale, although the actual value might need tweaking depending on the traffic profile of those sessions, i.e., high throughput, loss, bdp etc.
I’m planning some optimizations in bt area, beyond the recent work which has been focused on rack/tlp, but mainly around avoiding the clib_mem_allocs. Pretty interesting to see that even the rbtree pool is a source of contention at the worker scale you’re running. Should you be able to provide more details about the use case, we may be able to incorporate some forward looking optimizations. As previously mentioned, currently I’m not aware of anybody else running tcp with more than 8-16 workers. Regards, Florin > On Sep 7, 2026, at 1:55 AM, chris b via lists.fd.io > <[email protected]> wrote: > > Hi Florin > > I managed to get past this issue by seeding the 2 pools with pool_alloc > > void > tcp_bt_init (tcp_connection_t * tc) > { > tcp_byte_tracker_t *bt; > > bt = clib_mem_alloc (sizeof (tcp_byte_tracker_t)); > clib_memset (bt, 0, sizeof (tcp_byte_tracker_t)); > > //try and seed poll to prevent clib mem shuffling > pool_alloc (bt->samples, 64); > > rb_tree_init (&bt->sample_lookup); > > //try and seed the tree - index0 is reserved > pool_alloc (bt->sample_lookup.nodes, 65); > > bt->head = bt->tail = TCP_BTS_INVALID_INDEX; > tc->bt = bt; > } > > We havent even submitted this locally - i need to assess the memory impact > and come up with a value here. But initially I picked 64. Throughput has > returned to normal here and we are up at the higher worker count now. > > I see from submits you are actively working in this area - hence the reply > here. > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27169): https://lists.fd.io/g/vpp-dev/message/27169 Mute This Topic: https://lists.fd.io/mt/120698796/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
