From: "D. Wythe" <alibuda@linux.alibaba.com>
To: Wenjia Zhang <wenjia@linux.ibm.com>,
kgraul@linux.ibm.com, jaka@linux.ibm.com
Cc: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org
Subject: Re: [net-next 1/2] net/smc: allow confirm/delete rkey response deliver multiplex
Date: Wed, 8 Feb 2023 10:58:25 +0800 [thread overview]
Message-ID: <eed8b91e-0236-edc8-f744-e30adfff229f@linux.alibaba.com> (raw)
In-Reply-To: <95e117f1-6f05-1c15-cddd-38be9cf7dd52@linux.ibm.com>
On 2/8/23 7:15 AM, Wenjia Zhang wrote:
>
>
> On 07.02.23 08:36, D. Wythe wrote:
>> From: "D. Wythe" <alibuda@linux.alibaba.com>
>>
>> We know that all flows except confirm_rkey and delete_rkey are exclusive,
>> confirm/delete rkey flows can run concurrently (local and remote).
>>
>> Although the protocol allows, all flows are actually mutually exclusive
>> in implementation, dues to waiting for LLC messages is in serial.
>>
>> This aggravates the time for establishing or destroying a SMC-R
>> connections, connections have to be queued in smc_llc_wait.
>>
>> We use rtokens or rkey to correlate a confirm/delete rkey message
>> with its response.
>>
>> Before sending a message, we put context with rtokens or rkey into
>> wait queue. When a response message received, we wakeup the context
>> which with the same rtokens or rkey against the response message.
>>
>> Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
>> ---
>> net/smc/smc_llc.c | 174 +++++++++++++++++++++++++++++++++++++++++-------------
>> net/smc/smc_wr.c | 10 ----
>> net/smc/smc_wr.h | 10 ++++
>> 3 files changed, 143 insertions(+), 51 deletions(-)
>>
>
> [...]
>
>> +static int smc_llc_rkey_response_wake_function(struct wait_queue_entry *wq_entry,
>> + unsigned int mode, int sync, void *key)
>> +{
>> + struct smc_llc_qentry *except, *incoming;
>> + u8 except_llc_type;
>> +
>> + /* not a rkey response */
>> + if (!key)
>> + return 0;
>> +
>> + except = wq_entry->private;
>> + incoming = key;
>> +
>> + except_llc_type = except->msg.raw.hdr.common.llc_type;
>> +
>> + /* except LLC MSG TYPE mismatch */
>> + if (except_llc_type != incoming->msg.raw.hdr.common.llc_type)
>> + return 0;
>> +
>> + switch (except_llc_type) {
>> + case SMC_LLC_CONFIRM_RKEY:
>> + if (memcmp(except->msg.confirm_rkey.rtoken, incoming->msg.confirm_rkey.rtoken,
>> + sizeof(struct smc_rmb_rtoken) *
>> + except->msg.confirm_rkey.rtoken[0].num_rkeys))
>> + return 0;
>> + break;
>> + case SMC_LLC_DELETE_RKEY:
>> + if (memcmp(except->msg.delete_rkey.rkey, incoming->msg.delete_rkey.rkey,
>> + sizeof(__be32) * except->msg.delete_rkey.num_rkeys))
>> + return 0;
>> + break;
>> + default:
>> + pr_warn("smc: invalid except llc msg %d.\n", except_llc_type);
>> + return 0;
>> + }
>> +
>> + /* match, save hdr */
>> + memcpy(&except->msg.raw.hdr, &incoming->msg.raw.hdr, sizeof(except->msg.raw.hdr));
>> +
>> + wq_entry->private = except->private;
>> + return woken_wake_function(wq_entry, mode, sync, NULL);
>> +}
>> +
>
> s/except/expect/ ?
> Just kind of confusing
>
> [...]
Hi, Wenjia
Except is what I want to express.
It means that only the confirm and delete rkey can be processed in parallel. :-)
Thanks
D. Wythe
next prev parent reply other threads:[~2023-02-08 2:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 7:36 [net-next 0/2] Deliver confirm/delete rkey message in parallel D. Wythe
2023-02-07 7:36 ` [net-next 1/2] net/smc: allow confirm/delete rkey response deliver multiplex D. Wythe
2023-02-07 23:15 ` Wenjia Zhang
2023-02-08 2:58 ` D. Wythe [this message]
2023-02-07 7:36 ` [net-next 2/2] net/smc: make SMC_LLC_FLOW_RKEY run concurrently D. Wythe
2023-02-07 23:22 ` Wenjia Zhang
2023-02-07 23:29 ` [net-next 0/2] Deliver confirm/delete rkey message in parallel Wenjia Zhang
2023-02-08 3:04 ` D. Wythe
2023-02-08 3:09 ` D. Wythe
2023-02-21 18:41 ` Wenjia Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eed8b91e-0236-edc8-f744-e30adfff229f@linux.alibaba.com \
--to=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=jaka@linux.ibm.com \
--cc=kgraul@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=wenjia@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).