Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3121348pxm; Mon, 28 Feb 2022 12:28:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJwH6VDSOYK83cH1esxVI/l+UkgctCrB+uDPvMYmGoO76zc2ua8JuTKzAJ+L3Hhf//K94uwq X-Received: by 2002:aa7:9253:0:b0:4e1:53d4:c2c6 with SMTP id 19-20020aa79253000000b004e153d4c2c6mr23613622pfp.62.1646080127917; Mon, 28 Feb 2022 12:28:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646080127; cv=none; d=google.com; s=arc-20160816; b=BZzEteP/I7Rp7+tPrjm8KR+ahWfH19zGmV1z7ZMoVCYZeBjdJcJ0FYbOlr572nHrD1 8aGRAtz+KzeMkqIIe8+9aauIYHCryVXPncg/BG6taWv2kfIuFFX9A70k21thGXv0Q+dt B5sOAeyIXp6dmACPPMJDjRIbq+TMdRnTBFzxhvB0vOfu250ASojXupnr660yz5UNXMs9 PyFfdN/99FsgCl3AYAaCS2kcGaGx2fLdL1EDY4Q+PSMjdi+sua+j3R46pkXFjuiMiVnG 2VcgBiJpAJX+eO3klPi/UFQnpwcMNvhu7p6yPddgBbE8JE19sV5Vn9b3bN4xlFrV7zo2 nmPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:subject:message-id:date:from:mime-version :dkim-signature; bh=WWANl2bU08BWGa90Y/qLd7VLJFwABkNgOot098o/gR0=; b=nHrr4fFh+K8tuiBvZkZnbGlM70f0fXyCBYixP1mBo/KZUZsPLVw2XnIrTrDegJoxs8 l/awcuDaaw1H1cb7r+DkSvg+1fSuPMZQOQjHWlSgj7W+Vje+Wf0tSwe4Td+iwgB3GROM GDQTl5itVqfsjLuoPzqwtGbWR0p5cAfy2pRdtwT+R7/fSbIfKXCc23hzppPNBzdu3OIt mJnDUmRZAqWPXpFxOZO0hBpDuSfZPPXq0tILH0RWfE/UU/ll0aamblDrBFbFtywyEt6K warlTJzipW9Afbm+OeiVFLmtyJxdjlG4TX4KrvIppH+RZHbDJy5DO/40rXb/odOOH5nk 8U3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@umich.edu header.s=google-2016-06-03 header.b=UngaGXGl; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=umich.edu Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id m22-20020a656a16000000b00372b111bf20si12729698pgu.19.2022.02.28.12.28.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 12:28:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@umich.edu header.s=google-2016-06-03 header.b=UngaGXGl; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=umich.edu Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A2C5E1F3B6B; Mon, 28 Feb 2022 11:45:04 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238136AbiB1S7L (ORCPT + 99 others); Mon, 28 Feb 2022 13:59:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238126AbiB1S7J (ORCPT ); Mon, 28 Feb 2022 13:59:09 -0500 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21065522C8 for ; Mon, 28 Feb 2022 10:58:29 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id r13so26786511ejd.5 for ; Mon, 28 Feb 2022 10:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:from:date:message-id:subject:to; bh=WWANl2bU08BWGa90Y/qLd7VLJFwABkNgOot098o/gR0=; b=UngaGXGlpRAEOX282K6Oej/Wj0Z4mn5mesNLosXxAnPY30UDLwSGeYhnfQln4K1ijZ /Qfkbi8PdB63+SxoZYOXoBsGWWEyNvNXWix+UjkqBzdxuSOzDEQPp75tKnCgaCBAa0Ck oowK0OmROBkq0+3jWtHvmaAgF6+1fQz3vJ3+F5OMXTj1Ej88jSvY4+bOJqYcXfPt7WsP kXfYtmBQg9bS3eOFx9NoetNU9SO4lhTAlCTsphAAbHYrBF8wQ1N7jl3MM6k3hxowIkh/ t1R4eXdWAJs7q4jcTI/OK+rNGgCesLnsy3KkqhSe28FZ2+EINxCSxQ7YEroX7OEwwuBs gMxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WWANl2bU08BWGa90Y/qLd7VLJFwABkNgOot098o/gR0=; b=BFM/4EZAJdWbYsc94+0zCChAbqw6iogX3ROD4MBqk3lH06arD+YJO6hnpEs3mWMpav tglQs0yXVtfoy+1laZzABqV3sTBm1x1Fmbh6RBrEPeC7zaI8hkZnIbOHOUDBhERuAPyh IumyvWJGEhZYCceXLv3aIW6meLK2L0kK/YvEGPv5jD6yRpqTLiOxyZAmTc1C9RhhX0vk /ODO68H3N34C7KqMY8p6pDh1cvdzb8Ec1qMKSevJVPRqVC5qkYA2VOJtjqtD2iucNb0e kUt5nHWkwwxSG3HXQJZ0siL2HpsyS5DJqM4e87ILbD8qVNMdNgwBeMS7xwoK/UBxg5UD gokQ== X-Gm-Message-State: AOAM531yVtUI8qbCKmdxKjYo//b0TLHLWaz6DkaXg8yL4U1mg7vkw0Az 0VRfSiw22DFa9UD3TZB/LKpCRxF7NHy5qdoFVjzBNq6Z8vI= X-Received: by 2002:a17:907:b96:b0:6d0:ae6:d153 with SMTP id ey22-20020a1709070b9600b006d00ae6d153mr15758043ejc.699.1646074707216; Mon, 28 Feb 2022 10:58:27 -0800 (PST) MIME-Version: 1.0 From: Olga Kornievskaia Date: Mon, 28 Feb 2022 13:58:16 -0500 Message-ID: Subject: managing trunking To: linux-nfs , Trond Myklebust Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Hello folks, I would like to ask for what would be an acceptable solution to deal with created trunking connections when there is a change in trunking membership, specifically when a connection (ie., its endpoint) no longer is part of the same group. An inaction on the client's part would lead to unusable client. Would a proposal to destroy trunking connections in as part of DESTROY_SESSION be acceptable? The logic behind this solution is that trunking membership was established as a part of a session, each connection was tested to belong to trunkable server and added to that session. Once the session is destroy and new created there is no guarantee that the connections are to the same server that the new session is created for. Trunking membership can be re-established at a later time. I have some code that implements this solution but still needs some testing. Alternatively, if we keep connections past DESTROY_SESSION, then we need a way to test that the same connections belong to the new session that has been created, meaning that a probe for each connection on create_session to see if they still belong to the same server as the new session is created. Is that preferred over simply destroying connections? I'm going to work on implementing this too and posting as an alternative. It has been expressed several times that the ultimate goal is to do transport management in userspace so does it mean the solution to this is also in userspace? Should there be upcalls to user land on DESTROY_SESSION and CREATE_SESSION to destroy/create trunking respectively but triggered via user land. But in this approach, while this happens at user land speed, will we be allowing the client to get into a state where it's unusable (because its connections are talking to servers that don't belong to the same trunking group)? Or to prevent this, will we be allowing the userland to pause activities in the kernel until the transports are squared away? I just don't see how out-sourcing trunking membership changes to the user land is better than handling it in the kernel when no operations can proceed until trunking membership is corrected. Any feedback on the approaches or its alternatives would be much appreciated. Thank you for the feedback. Thank you.