Update patch set 3

Patch Set 3:

(1 comment)

Patch-set: 3
Attention: {"person_ident":"Gerrit User 1000005 \u003c1000005@035e6965-6537-41bd-912c-053f3cf69326\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_1000005\u003e replied on the change"}

9ec7279329a4a3f5558bc5deaab44dcec20363f9

@@ -0,0 +1,21 @@
+{
+  "comments": [
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "9e3240a9_3cc9f3e8",
+        "filename": "/PATCHSET_LEVEL",
+        "patchSetId": 3
+      },
+      "lineNbr": 0,
+      "author": {
+        "id": 1000005
+      },
+      "writtenOn": "2024-04-12T23:53:48Z",
+      "side": 1,
+      "message": "Quoting from the \"Depends\" libosmocore patch discussion:\n\n\u003e For this one, my aim was to say that osmo-trx is doing it that way, not that you \u003e should do it that way.\n\noh, misunderstanding.\n\n\u003e If you plan on keep the mutex locked while you gather counters from nft\n\nin this patch:\nthe stats lock is held while updating the rate_ctrs only, locking only *after* the nft command has run and returned the complete response in a char buffer.\n\nI expect running through that buffer to be very fast, so i lock stats reporting once all around the buffer parsing. If it turns out wrong, we can unlock and re-lock the mutex after every N items (or every N ms?), which would remove \"all\" blocking of stats. (It is important to keep counters for each HNB in sync, but not important to keep HNBs in sync with each other.)\nI expect buffer parsing to already be imperceptibly fast; this is O(n) of pure pointer arithmetic, no syscalls.\n\n\u003e most probably blocking the main thread also for the same amount of time.\n\n(I\u0027ve written this before in different places, but allow me to re-post, to make sure it is mentioned here:)\n\nBlocking of the main thread can happen with this patch, at the times when the main thread wants to run a quick nft command.\n\nThis happens only at HNBAP HNB Register and Deregister, i.e. when a hNodeB shows up or disappears; to set up / remove nft counter rules. Here the main thread may have to wait for the second thread querying the counters from nftables. There is an ascii art of it in this patch.\n\nTo circumvent this blocking, an inter-thread queue can be introduced to tell the second thread to carry out the nft commands the main thread wants to run.\n\nThis is not implemented in this patch on purpose, because:\nThe HNB Register / Deregister are rare events, and reading counters doesn\u0027t really take all that long, either. It may well turn out to be overkill to even have a thread for nftables in the first place. It is slow for large numbers of items, but counters for under 1000 HNB from nft should be fast.",
+      "revId": "9ec7279329a4a3f5558bc5deaab44dcec20363f9",
+      "serverId": "035e6965-6537-41bd-912c-053f3cf69326"
+    }
+  ]
+}