All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.