From: Wen Gu <guwen@linux.alibaba.com>
To: Karsten Graul <kgraul@linux.ibm.com>, Tony Lu <tonylu@linux.alibaba.com>
Cc: netdev@vger.kernel.org, linux-s390@vger.kernel.org,
linux-rdma@vger.kernel.org, jacob.qi@linux.alibaba.com,
xuanzhuo@linux.alibaba.com, dust.li@linux.alibaba.com,
davem@davemloft.net, kuba@kernel.org, guwen@linux.alibaba.com
Subject: Re: [PATCH net 4/4] net/smc: Fix wq mismatch issue caused by smc fallback
Date: Thu, 4 Nov 2021 12:39:46 +0800 [thread overview]
Message-ID: <c26da743-36fb-e1c3-c13f-460b3d2dbb4c@linux.alibaba.com> (raw)
In-Reply-To: <f51d3e86-0044-bc92-cdac-52bd978b056b@linux.ibm.com>
On 2021/11/2 5:25 pm, Karsten Graul wrote:
> On 01/11/2021 07:15, Wen Gu wrote:
>> Before explaining my intentions, I thought it would be better to describe the issue I encountered first:
>>
>> In nginx/wrk tests, when nginx uses TCP and wrk uses SMC to replace TCP, wrk should fall back to TCP and get correct results theoretically, But in fact it only got all zeros.
>
> Thank you for the very detailed description, I now understand the situation.
>
> The fix is not obvious and not easy to understand for the reader of the code,
> did you think about a fix that uses own sk_data_ready / sk_write_space
> implementations on the SMC socket to forward the call to the clcsock in the
> fallback situation?
>
> I.e. we already have smc_tx_write_space(), and there is smc_clcsock_data_ready()
> which is right now only used for the listening socket case.
>
> If this works this would be a much cleaner and more understandable way to fix this issue.
>
Thanks for your suggestions about implementing SMC own sk_data_ready /
sk_write_space and forwarding call to clcsock. It's a great idea. But I
found some difficulties here in implementation process:
In my humble opinion, SMC own sk_write_space implementation should be
called by clcsk->sk_write_space and complete the following steps:
1) Get smc_sock through clcsk->sk_user_data, like what did in
smc_clcsock_data_ready().
2) Forward call to original clcsk->sk_write_space, it MIGHT wake up
clcsk->sk_wq, depending on whether certain conditions are met.
3) Wake up smc sk->sk_wq to nodify application if clcsk->sk_write_space
acctually wakes up clcsk->sk_wq.
In step 3), it seems a bit troublesome for SMC to know whether
clcsk->sk_write_space acctually wake up clcsk->sk_wq, which is a black
box to SMC.
There might be a feasible way that add a wait_queue_head_t to
clcsk->sk_wq and report to SMC when clcsk->sk_wq is waked up. Then SMC
can report to application by waking up smc sk->sk_wq. But that seems to
be complex and redundancy.
I'm looking forward to hear your opinion about it. Thank you!
cheers,
Wen Gu
next prev parent reply other threads:[~2021-11-04 4:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 8:52 [PATCH net 0/4] Fixes for SMC Tony Lu
2021-10-27 8:52 ` [PATCH net 1/4] Revert "net/smc: don't wait for send buffer space when data was already sent" Tony Lu
2021-10-27 10:21 ` Karsten Graul
2021-10-27 15:08 ` Jakub Kicinski
2021-10-27 15:38 ` Karsten Graul
2021-10-27 15:47 ` Jakub Kicinski
2021-10-28 6:48 ` Tony Lu
2021-10-28 11:57 ` Karsten Graul
2021-10-28 14:38 ` Jakub Kicinski
2021-11-01 7:04 ` Tony Lu
2021-11-02 9:17 ` Karsten Graul
2021-11-03 3:06 ` Tony Lu
2021-11-06 12:46 ` Karsten Graul
2021-10-27 8:52 ` [PATCH net 2/4] net/smc: Fix smc_link->llc_testlink_time overflow Tony Lu
2021-10-27 10:24 ` Karsten Graul
2021-10-28 6:52 ` Tony Lu
2021-10-27 8:52 ` [PATCH net 3/4] net/smc: Correct spelling mistake to TCPF_SYN_RECV Tony Lu
2021-10-27 10:23 ` Karsten Graul
2021-10-28 6:53 ` Tony Lu
2021-10-27 8:52 ` [PATCH net 4/4] net/smc: Fix wq mismatch issue caused by smc fallback Tony Lu
2021-10-28 14:16 ` Karsten Graul
2021-10-29 9:40 ` Karsten Graul
2021-11-01 6:15 ` Wen Gu
2021-11-02 9:25 ` Karsten Graul
2021-11-03 8:56 ` Wen Gu
2021-11-04 4:39 ` Wen Gu [this message]
2021-11-06 12:51 ` Karsten Graul
2021-11-10 12:50 ` Wen Gu
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=c26da743-36fb-e1c3-c13f-460b3d2dbb4c@linux.alibaba.com \
--to=guwen@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=dust.li@linux.alibaba.com \
--cc=jacob.qi@linux.alibaba.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=tonylu@linux.alibaba.com \
--cc=xuanzhuo@linux.alibaba.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