From: Tom Talpey <tom@talpey.com>
To: Steve French <smfrench@gmail.com>,
Shyam Prasad N <nspmangalore@gmail.com>
Cc: CIFS <linux-cifs@vger.kernel.org>, Bharath S M <bharathsm@microsoft.com>
Subject: Re: [PATCH] cifs: use the least loaded channel for sending requests
Date: Tue, 20 Dec 2022 13:18:42 -0500 [thread overview]
Message-ID: <6b39f048-b292-a0fd-af8a-abad97d22ed7@talpey.com> (raw)
In-Reply-To: <CAH2r5muGBpwvpt6tTXDj2s=UHhJyG1=p94mcTaZ7QbrpuZ2R+w@mail.gmail.com>
I'd suggest a runtime configuration, personally. A config option
is undesirable, because it's very difficult to deploy. A module
parameter is only slightly better. The channel selection is a
natural for a runtime per-operation decision. And for the record,
I think a round-robin selection is a bad approach. Personally
I'd just yank it.
I'm uneasy about ignoring the channel bandwidth and channel type.
Low bandwidth channels, or mixing RDMA and non-RDMA, are going to
be very problematic for bulk data. In fact, the Windows client
never mixes such alternatives, it always selects identical link
speeds and transport types. The traffic will always find a way to
block on the slowest/worst connection.
Do you feel there is some advantage to mixing traffic? If so, can
you elaborate on that?
The patch you link to doesn't seem complete. If min_in_flight is
initialized to -1, how does the server->in_flight < min_in_flight
test ever return true?
Tom.
On 12/20/2022 9:47 AM, Steve French wrote:
> maybe a module load parm would be easier to use than kernel config
> option (and give more realistic test comparison data for many)
>
> On Tue, Dec 20, 2022 at 7:29 AM Shyam Prasad N <nspmangalore@gmail.com> wrote:
>>
>> Hi Steve,
>>
>> Below is a patch for a new channel allocation strategy that we've been
>> discussing for some time now. It uses the least loaded channel to send
>> requests as compared to the simple round robin. This will help
>> especially in cases where the server is not consuming requests at the
>> same rate across the channels.
>>
>> I've put the changes behind a config option that has a default value of true.
>> This way, we have an option to switch to the current default of round
>> robin when needed.
>>
>> Please review.
>>
>> https://github.com/sprasad-microsoft/smb3-kernel-client/commit/28b96fd89f7d746fc2b6c68682527214a55463f9.patch
>>
>> --
>> Regards,
>> Shyam
>
>
>
next prev parent reply other threads:[~2022-12-20 18:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-20 13:28 [PATCH] cifs: use the least loaded channel for sending requests Shyam Prasad N
2022-12-20 14:47 ` Steve French
2022-12-20 18:18 ` Tom Talpey [this message]
2022-12-21 15:33 ` Shyam Prasad N
2022-12-21 16:46 ` Tom Talpey
2022-12-22 9:56 ` Shyam Prasad N
2022-12-23 14:16 ` Shyam Prasad N
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=6b39f048-b292-a0fd-af8a-abad97d22ed7@talpey.com \
--to=tom@talpey.com \
--cc=bharathsm@microsoft.com \
--cc=linux-cifs@vger.kernel.org \
--cc=nspmangalore@gmail.com \
--cc=smfrench@gmail.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).