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@xxxxxxxxx> 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
