Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Fri, 7 Jul 2023 11:40:41 -0400
Message-ID: <CAN-5tyGb0xb1-C9781gdkfPRNtKSixT_TfU44VV6FRCZooixXw@mail.gmail.com>
Subject: trunking rules
To:     linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi folks,

I'm looking for some guidance/consensus/agreement on what should be
trunking rules.

Prior to adding MDS session trunking, we had pnfs session trunking for
a long time. In GETDEVICEINFO the server would return a list of IPs
and the client, after verifying that it's allowed to trunk, would then
use. The number of IPs isn't limited by number but rather by the
sizeof deviceinfo structure (gdia_macount). At the same time, if
GETDEVICEINFO returned IPs that were in the same as MDS, then those
IPs would be squashed (I'm gathering the logic was if DS=MDS then it's
MDS trunking and that wasn't supported).

Fast forward now, MDS trunking is supported but controlled and limited
by the mount parameter max_connect.
What kind of rule should be used for trunking when DS=MDS now?
(1) Treat it strictly as MDS trunking. If no max_connect is given on
mount, then even if GETDEVICEINFO returns multiple IPs everything is
going to be squashed. If max_connect is given then it's the
max_connect that limits the number of trunks and not like other pnfs
trunking where it's the size of getdeviceinfo structure?
(2) Treat it as DS trunking and disregard max_connect constraints
because after all it is triggered as pnfs trunking not MDS trunking?

Or should max_connect be now required for any kind of trunking DS or
MDS trunking? Though I'm not in favor of this as it seems to defeat
the purpose of specifying a size of GETDEVICEINFO reply and just limit
it to max_connect always.

Thank you.