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;
MIME-Version: 1.0
References: <20201006151335.GB28306@fieldses.org> <df7b7b26-c6a7-9e6f-edf6-e3c858623462@math.utexas.edu>
In-Reply-To: <df7b7b26-c6a7-9e6f-edf6-e3c858623462@math.utexas.edu>
From:   Igor Ostrovsky <igor@purestorage.com>
Date:   Wed, 7 Oct 2020 09:28:00 -0700
Message-ID: <CAGrwUG4TSTBWXZRRbYLvTyavDkMpryXdx8AREm-13dkueG99NQ@mail.gmail.com>
Subject: Re: unsharing tcp connections from different NFS mounts
To:     Patrick Goetz <pgoetz@math.utexas.edu>
Cc:     "J. Bruce Fields" <bfields@fieldses.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Oct 7, 2020 at 6:57 AM Patrick Goetz <pgoetz@math.utexas.edu> wrote:

> I don't see how sharing a TCP connection can result in a performance
> regression (the performance degradation of *not* sharing a TCP
> connection is why HTTP 1.x is being replaced), or how using different IP
> addresses on the same interface resolves anything.  Does anyone have an
> explanation?
>

The two IPs give you a form of QoS. So, it's about performance isolation
across the mounts, not about improving the aggregate performance.

The example I mentioned was this one:

    dd if=/dev/zero of=/mnt/mount1/zeros &
    ls /mnt/mount2/

The writes to /mnt/mount1 keep the transport busy transmitting data. As
a result, the "ls" GETATTR (or whatever RPC) needs to wait on the
single transport, potentially for seconds. Putting the two mounts on
different IPs solves the problem, at least prior to trunking discovery.