ofiwg / libfabric

Open Fabric Interfaces

Home Page:http://libfabric.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

fi_tsendmsg argument question

hppritcha opened this issue · comments

Okay, I've got another question pertaining to the behavior of a new provider I'm working with.

Our application makes use of the fi_tsendmsg method with a zero length message. We're just trying to get a cq event generated with a particular tag value at the receiver.

So we are initializing our struct fi_msg_tagged tagged_msg argument as follows:

        tagged_msg.msg_iov = NULL;
        tagged_msg.desc = NULL;
        tagged_msg.iov_count = 0;
        tagged_msg.addr = ofi_req->remote_addr;
        /**
        * We must continue to use the user's original tag but remove the
        * sync_send protocol tag bit and instead apply the sync_send_ack
        * tag bit to complete the initator's sync send receive.
        */
        tagged_msg.tag = (wc->tag | ompi_mtl_ofi.sync_send_ack) & ~ompi_mtl_ofi.sync_send;
        tagged_msg.context = NULL;
        tagged_msg.data = 0;

the provider is checking that msg_iov is not null and that the iov_count is not equal to one.
Is it okay if the msg_iov field is NULL and hence iov_count being set to 0?

We're using this code successfully with the AWS EFA, PSM2, and RXM;verbs providers.

A 0-length message is permitted by the API. I don't know if the provider you're using doesn't support 0-length sends or wants an empty iovec. But I would expect your code to work. I did a very quick check, and I think the udp, tcp, and sockets providers also support an iov_count = 0, with a NULL iov (on their supported recv calls).

closing this as we've identified the issue in the provider. thanks @shefty