Attention is currently required from: laforge, pespin.
1 comment:
Patchset:
(I wrote the comment above this morning but actually saw just now I forgot to press the "submit" but […]
I think it makes a lot of sense to keep the patches separate as they are.
The patch wrapping a thread around existing code is very nicely orthogonal to the actual nft activity, and it is nice to see exactly where the mutexes etc are added, without the nft implementation along with it to clutter up the attention span.
osmo-trx's use of multi-threaded counters: do you have a pointer? I was looking around and apparently hadn't found it... thanks!
You say in osmo-trx "we do things a bit adhoc" and further below you say that's "how it should be done" -- IIUC an intermediate storage with mutexes.
The underlying point is whether the occasional short blocking for HNB Register and HNB DeRegister (rare events) are noticeable enough to warrant further effort on that.
If those blockings of the main thread are not desirable, it seems the best way is a queue fd (osmo_it_q?) because other than mutexes, it avoids all blocking by design.
You say "it's broken", yet the patch is actually already being run successfully.
I see no inconsistencies nor brokenness, I'd be glad to hear some technical detail to back up your claims.
Scalability is an open point -- we are only now able to gather the empirical data on that. My experience is that nft below 1000 items is very fast, and only becomes prohibitively slow with higher numbers, with some exponentiality kicking in. I am not fully convinced that we even need a separate thread.
In summary, am interested in how osmo-trx does it; otherwise do not agree / do not yet see the points that were claimed; instead, am engaging in scalability discussion.
To view, visit change 36385. To unsubscribe, or for help writing mail filters, visit settings.