Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Chuck Lever <chuck.lever@oracle.com>
To:     Dan Aloni <dan@kernelim.com>, Olga Kornievskaia <aglo@umich.edu>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Anna Schumaker <anna.schumaker@netapp.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>
Subject: Re: [PATCH v1 0/8] sysfs files for multipath transport control
Thread-Topic: [PATCH v1 0/8] sysfs files for multipath transport control
Thread-Index: AQHXA8HF/Q0BfS8EzUGtVa8pd9CwgqpwKIAAgAOrQgCAAHANgA==
Date:   Thu, 4 Mar 2021 18:39:10 +0000
Message-ID: <E076EDFC-A53B-40A5-A62E-422995FAC8A4@oracle.com>
References: <20210215174002.2376333-1-dan@kernelim.com>
 <CAN-5tyGw3D-+emeQhu31agom9yuZ9=PL6YUVyEKiR-n2q9uE3A@mail.gmail.com>
 <20210304115806.rvoeju7gmqyd3v6i@gmail.com>
In-Reply-To: <20210304115806.rvoeju7gmqyd3v6i@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7BC223CBADF3164693ECDFAA038E82F3@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8a2e0cff-b891-453f-9615-08d8df3ccced
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2021 18:39:10.0486
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4MaCd4RBgmwMuOyRR8Af/EOztrnsxG8AWdI1YUHVvFo8zf24ki5fINB902Iv4NuVugaLo0o6SoBLUGVR47P4lA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3031
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9913 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 phishscore=0
 malwarescore=0 spamscore=0 mlxlogscore=999 suspectscore=0 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103040088
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9913 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 phishscore=0 mlxscore=0
 suspectscore=0 adultscore=0 malwarescore=0 priorityscore=1501 bulkscore=0
 lowpriorityscore=0 spamscore=0 mlxlogscore=999 clxscore=1011
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103040088
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Mar 4, 2021, at 6:58 AM, Dan Aloni <dan@kernelim.com> wrote:
>=20
> On Mon, Mar 01, 2021 at 10:56:22PM -0500, Olga Kornievskaia wrote:
>> Hi Dan,
>>=20
>> On Mon, Feb 15, 2021 at 12:43 PM Dan Aloni <dan@kernelim.com> wrote:
>>>=20
>>> Hi Anna,
>>>=20
>>> This patchset builds ontop v2 of your 'sysfs files for changing IP' cha=
ngeset.
>>>=20
>>> - The patchset adds two more sysfs objects, for one for transport and a=
nother
>>>  for multipath.
>>> - Also, `net` renamed to `client`, and `client` now has symlink to its =
principal
>>>  transport. A client also has a symlink to its `multipath` object.
>>> - The transport interface lets you change `dstaddr` of individual trans=
ports,
>>>  when `nconnect` is used (or if it wasn't used and these were added wit=
h the
>>>  new interface).
>>> - The interface to add a transport is using a single string written to =
'add',
>>>  for example:
>>>=20
>>>       echo 'dstaddr 192.168.40.8 kind rdma' \
>>>> /sys/kernel/sunrpc/client/0/multipath/add
>>>=20
>>> These changes are independent of the method used to obtain a sunrpc ID =
for a
>>> mountpoint. For that I've sent a concept patch showing an fspick-based
>>> implementation: https://marc.info/?l=3Dlinux-nfs&m=3D161332454821849&w=
=3D4
>>=20
>> I'm confused: does this allow adding arbitrary connections between a
>> client and some server IP to an existing RPC client? Given the above
>> description, that's how it reads to me, can you clarify please. I
>> thought it was something specifically for v3 (because it has no
>> concept of trunking). As for NFSv4 there is a notion of getting server
>> locations via FS_LOCATION and doing trunking (ie multipathing)? I
>> don't see how this code restricts the addition of transports to v3.
>=20
> Indeed, there's no restriction to NFSv3.
>=20
> There can be potential uses for this for NFSv4 too. FS_LOCATIONS serving
> as recommendation to which hosts the client can connect, while smart
> load-balancing logic in userspace can determine to which subset of these
> servers each client in a cluster should actually connect (a full mesh
> is not always desired).
>=20
> At any case, if this restriction is desired, we can add a new sunrpc
> client flag for that and pass it only in NFSv3 client init.

IMO an NFSv3-only policy should not be built into this API.

This is a user-space / kernel API, not something that is an administrative
interface. The administrative interface, which is the place to apply an
NFSv3-only policy, would use this sysfs API. So would smart load-
balancing logic based on fs_locations.

If the API is under /sys/kernel/sunrpc/client, then including NFS-specific
controls is a layering violation. Consider that the kernel can send
multiple protocols over the same connection (NFSv3 and NFSACL, eg).


--
Chuck Lever