Some additions below.
On Wed, Mar 20, 2019 at 10:52:46AM +0100, Harald Welte wrote:
Where is this useful? There's at least two common
use cases:
* allocation of message buffers without having to worry about msgb ownership
I forgot here that this obviously only works if the msgb is created + consumed
within the same select dispatch. If e.g. the msgb is enqueued on a transmit queue,
you would have to talloc_steal() / talloc_reparent() it to a different context
before returning from the select dispatch.
In terms of our usual use cases, I see the following scenarios:
a) incoming, locally handled message
The msgb can normally be allocated from OTC_SELECT as we are processing the
entire msgb within the select dispatch. If we end up queueing it somewhere,
we need to steal it.
b) incoming, forwarded message
if we already know we'll forward it (e.g. in gb-proxy or bsc_nat), we might
directly allocate it from OTC_GLOBAL or any of its children.
c) outgoing message
As we're operating in non-blocking mode, we can never make the assumption
that any of the outbound sockets will be write-able. Hence, we always have
a transmit queue, and as a result we have to allocate from OTC_GLOBAL or
one of its children.
d) local primitives (osmo_prim)
As osmo_prim are msgb-wrapped, and primitives [at least for now] are always
only between our local SAP user and provider (or vice versa) we might use
OTC_SELECT here, and make sure that all users that want to recycle a osmo_prim
msgb will steal it, if needed (I don't think that's a very valid use case).
This applies both ways: for primitives from the provider to the user,
as well as the other way around.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)