[mpich-discuss] MPI_Send over ibverbs
Niyaz Murshed
Niyaz.Murshed at arm.com
Tue Oct 8 11:08:18 CDT 2024
Are you talking about the ack of RC connection? Or is it MPI’s scope?
From: Raffenetti, Ken <raffenet at anl.gov>
Date: Tuesday, October 8, 2024 at 11:05 AM
To: discuss at mpich.org <discuss at mpich.org>
Cc: Niyaz Murshed <Niyaz.Murshed at arm.com>, nd <nd at arm.com>
Subject: Re: [mpich-discuss] MPI_Send over ibverbs
An internal acknowledgement message is sent from the receiver to the sender indicating that a particular synchronous send operation was matched.
Ken
From: Niyaz Murshed via discuss <discuss at mpich.org>
Date: Tuesday, October 8, 2024 at 10:49 AM
To: discuss at mpich.org <discuss at mpich.org>
Cc: Niyaz Murshed <Niyaz.Murshed at arm.com>, nd <nd at arm.com>
Subject: Re: [mpich-discuss] MPI_Send over ibverbs
Thank you for the reply Joachim. ‘MPI_Ssend has the requirement to return after the message was matched at the receiver’ – From the above statement, how do the sender know that the receiver called a matching receive? I am asking from the point
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Thank you for the reply Joachim.
‘MPI_Ssend has the requirement to return after the message was matched at
the receiver’ –
>From the above statement, how do the sender know that the receiver called a matching receive?
I am asking from the point of view of MPI_Send over RDMA.
In case of RDMA, internally it will call rdma_send which does not know when a matching rdma_recv was called on destination. How do the sender knows when rdma_recv was called?
From: Joachim Jenke via discuss <discuss at mpich.org>
Date: Tuesday, October 8, 2024 at 9:42 AM
To: discuss at mpich.org <discuss at mpich.org>
Cc: Joachim Jenke <jenke at itc.rwth-aachen.de>
Subject: Re: [mpich-discuss] MPI_Send over ibverbs
Hi,
none of the MPI send calls has a requirement to return after the message
was received. MPI_Send can return as soon as the caller can write to
buffer without impact to the data being transferred. This might be after
the data is put to the network, or the MPI library copied the data to an
internal buffer.
MPI_Ssend has the requirement to return after the message was matched at
the receiver, which implies that the matching Receive was called. But it
still does not require that the message was received at this point.
Best
Joachim
Am 08.10.24 um 04:55 schrieb Niyaz Murshed via discuss:
> Hi,
>
> Is there a way to check the implementation of MPI_Send?
>
> As I understand there is an implicit barrier which allows MPI_Send to
> return only after the buffer is received by the destination.
>
> How is this communication done? How does the destination notify the
> sender that buffer is received?
>
> How is this implemented when using rocev2 ?
>
> Regards,
>
> Niyaz
>
>
> _______________________________________________
> discuss mailing list discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://urldefense.us/v3/__https://lists.mpich.org/mailman/listinfo/discuss__;!!G_uCfscf7eWS!clHAN2yUbb4u0UWY1rvT7poZ5reFQeBFbFsiBbEnLjTWD2fqnaBkgnuY3LdrIBRBsbqAO6I7JntaZdydYCc$ <https://urldefense.us/v3/__https:/lists.mpich.org/mailman/listinfo/discuss__;!!G_uCfscf7eWS!aTxlD8Xx22PDuMXv--UZcA68fdpz5fzzNTbFlnm4W8ILFpny-KqRwNDxs2-iX7Ob14g7ReYsSsFBpE5IiC8$>
--
Dr. rer. nat. Joachim Jenke
IT Center
Group: High Performance Computing
Division: Computational Science and Engineering
RWTH Aachen University
Seffenter Weg 23
D 52074 Aachen (Germany)
Tel: +49 241 80- 24765
Fax: +49 241 80-624765
jenke at itc.rwth-aachen.de
https://urldefense.us/v3/__http://www.itc.rwth-aachen.de__;!!G_uCfscf7eWS!clHAN2yUbb4u0UWY1rvT7poZ5reFQeBFbFsiBbEnLjTWD2fqnaBkgnuY3LdrIBRBsbqAO6I7JntaChbKGQQ$ <https://urldefense.us/v3/__http:/www.itc.rwth-aachen.de__;!!G_uCfscf7eWS!aTxlD8Xx22PDuMXv--UZcA68fdpz5fzzNTbFlnm4W8ILFpny-KqRwNDxs2-iX7Ob14g7ReYsSsFBFKt98Uc$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20241008/31f73a8b/attachment-0001.html>
More information about the discuss
mailing list