tag_recv_nb takes UCXWorker or UCXEndpoint

[jakirkham]

Currently tag_recv_nb takes a UCXWorker or a UCXEndpoint. Though it looks like we always supply a UCXEndpoint when calling tag_recv_nb. Given this, do we actually have a need to supply both? Or should we simplify the API to only take a UCXEndpoint? Mentioning this in part as other send/recv calls do the latter as well.

[jakirkham]

Related it appears _inflight_msgs is defined in UCXWorker and UCXEndpoint. Do both classes need to track this? Or would it be possible to track this in just one of them?

[jakirkham]

As UCXEndpoint has an associated UCXWorker, we might be able to just take a UCXEndpoint in tag_recv_nb and retrieve the associated UCXWorker from it where needed.

[madsbk]

This is on purpose, tag_recv_nb() use to take a UCXEndpoint but as part of the effort of separating the low-level UCX API from the higher level Python/Async API, tag_recv_nb() now takes a UCXWorker, which match the UCX API.

[jakirkham]

Yeah that makes sense. Was looking at the UCX API and noticed that as well. Just wondering if there's an opportunity here to deduplicate things a bit. WDYT?

[jakirkham]

Based on today's meeting, it sounds like @MattBBaker's works will help us solve this by using addresses. Though please correct me if I misunderstood anything, Matt 🙂

[MattBBaker]

Just now noticed this, but I don't think so. The use case for UCXWorker address is that it is created, then sent over the network where the otherside gets it as a buffer that is a magic byte string. That byte string is fed into the ucp_create_ep() with a flag that says, "Your input data is to be interpreted as a ucp_address_t" and you get an EP from that.