Use of owner_context and peer_context in fi_peer_rx_entry

[sunkuamzn]

Hi, I'm working with @shijin-aws on implementing the peer API to offload shared memory message processing from the EFA provider to the SHM provider.

We want some clarification about the use of owner_context and peer_context fields in the fi_peer_rx_entry struct. I saw that the SHM provider is currently using both fields. But I'm not familiar with the internals of the SHM provider.

We want to use one of these fields to point to a struct that contains the data received during an unexpected receive. Which field is better suited for that? Thanks!

[aingerson]

Hi @sunkuamzn The owner_context and peer_context can be used however you want. The owner_context is set by the owner of the srx and can only be used by the owner and the peer_context can only be used by the peer (the one calling into the srx to get a msg). The reason shm uses both is because it can be both an owner and a peer. It uses the owner_context to point to the head rx_entry (this is only for FI_MULTI_RECV). And it uses the peer_context to point to the incoming cmd when posting an unexpected message.

[shijin-aws]

My understanding after reading SHM's code base is that SHM is using owner_context to pass the ptr to the owner_entry of the multi-recv receive buffer. As for peer_context, it is the context of smr_cmd that used to progress the cmd. But there is no explanation on these two fields in the man page, so we want some clarification

[aingerson]

@shijin-aws I think the fields were added after the peer API was defined so I guess they didn't make it in there. I will clarify in the man pages. Thanks!

[shijin-aws]

@aingerson thank you for the quick answer!

[sunkuamzn]

Thanks @aingerson! The man pages also refer to user_context field which is actually called owner_context in the code.

[aingerson]

@sunkuamzn @shijin-aws Opened #8648 to clarify usage. Let me know if you think that's sufficient!

[shijin-aws]

PR is merged and the discussion can be closed.