Attention is currently required from: laforge, pespin.
arehbein has posted comments on this change. (
https://gerrit.osmocom.org/c/osmo-bts/+/31533 )
Change subject: common: Have PCU socket connection use osmo_wqueue
......................................................................
Patch Set 4:
(6 comments)
File include/osmo-bts/pcuif_proto.h:
https://gerrit.osmocom.org/c/osmo-bts/+/31533/comment/f10f9ec7_96d976af
PS2, Line 8: #define PCU_SOCK_QLENGTH_MAX_DEFAULT 10
Ack
Ah or course I see what you mean, thanks for
the explanation. I have put it in `bts.h`. It might also make sense to move it to
libosmocore, because 10 seems to be the implicit default wqueue length (I grepped for
calls to `osmo_wqueue_setup()`) for Osmocom's pcu, bsc and bts.
File src/common/pcu_sock.c:
https://gerrit.osmocom.org/c/osmo-bts/+/31533/comment/3cda8dd9_45754a6b
PS2, Line 1092: return -1;
osmo_wqueue_bfd_cb: […]
Done
https://gerrit.osmocom.org/c/osmo-bts/+/31533/comment/3173124d_1004b04e
PS2, Line 1102: osmo_fd_write_disable(&state->upqueue.bfd);
Ah alright, good to know (just read a bit into the code/`fd_set`-related matters).
This is wrong. You should disable the bfd after
successful write() only if the queue is empty.
In the core of the function body before my change, `bfd` was already disabled similarly -
only if the queue wasn't empty - and before writing. That's what I meant by saying
I didn't change the logic (as the loop becoming part of `osmo_wqueue_bfd_cb` was the
main change).
`osmo-bts at 495cf39cb9e6bb54a7a5fd1195988f4a03f3171a` on branch master:
```
while (!llist_empty(&state->upqueue)) {
struct msgb *msg, *msg2;
struct gsm_pcu_if *pcu_prim;
/* peek at the beginning of the queue */
msg = llist_entry(state->upqueue.next, struct msgb, list);
pcu_prim = (struct gsm_pcu_if *)msg->data;
osmo_fd_write_disable(bfd);
/* bug hunter 8-): maybe someone forgot msgb_put(...) ? */
if (!msgb_length(msg)) {
LOGP(DPCU, LOGL_ERROR, "message type (%d) with ZERO "
"bytes!\n", pcu_prim->msg_type);
goto dontsend;
}
/* try to send it over the socket */
rc = write(bfd->fd, msgb_data(msg), msgb_length(msg));
if (rc == 0)
goto close;
if (rc < 0) {
if (errno == EAGAIN) {
osmo_fd_write_enable(bfd);
break;
}
goto close;
}
dontsend:
/* _after_ we send it, we can deueue */
msg2 = msgb_dequeue(&state->upqueue);
assert(msg == msg2);
msgb_free(msg);
}
return 0;
```
I think I've seen the same snippet in other socket write callbacks of ours, too.
The enable happens in `pcu_sock_send()` or if `-EAGAIN` is received.
https://gerrit.osmocom.org/c/osmo-bts/+/31533/comment/96912ed1_9864d2c1
PS2, Line 1181: osmo_wqueue_init(&state->upqueue, PCU_SOCK_QLENGTH_MAX_DEFAULT);
I'm fine with whatever but use WQUEUE instead of
the QLENGTH stuff :)
Done
File src/common/pcu_sock.c:
https://gerrit.osmocom.org/c/osmo-bts/+/31533/comment/16971e3b_72bf6e64
PS3, Line 993: LOGP(DLGLOBAL, LOGL_NOTICE, "PCU not reacting (more thatn %u
messages waiting). Closing connection\n",
the code above is using DPCU everywhere, so I
don't see a need to use a non-PCU-specific log subsyst […]
Ah I see. I just went
to the `LOGP` define and the comment above there doesn't mention that there are
project-specific logging related headers like `include/osmocom/bsc/debug.h`.
If `include/osmocom/<component>/debug.h` exists for different projects, it might be
worth moving that code to libosmocore (seems like it's rather
'cross-component').
https://gerrit.osmocom.org/c/osmo-bts/+/31533/comment/3cdf00b0_e31e3f15
PS3, Line 993: LOGP(DLGLOBAL, LOGL_NOTICE, "PCU not reacting (more thatn %u
messages waiting). Closing connection\n",
typo: than
Done
--
To view, visit
https://gerrit.osmocom.org/c/osmo-bts/+/31533
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: Ia6e61dda4b3cd4bba76e6acb7771d70335062fe1
Gerrit-Change-Number: 31533
Gerrit-PatchSet: 4
Gerrit-Owner: arehbein <arehbein(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 02 Mar 2023 22:13:03 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: arehbein <arehbein(a)sysmocom.de>
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment