Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D02F0ECDE47 for ; Thu, 8 Nov 2018 16:35:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A17F92077B for ; Thu, 8 Nov 2018 16:35:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A17F92077B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=candelatech.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726710AbeKICLu (ORCPT ); Thu, 8 Nov 2018 21:11:50 -0500 Received: from mail2.candelatech.com ([208.74.158.173]:55924 "EHLO mail2.candelatech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726421AbeKICLu (ORCPT ); Thu, 8 Nov 2018 21:11:50 -0500 Received: from [192.168.1.47] (unknown [50.34.223.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail2.candelatech.com (Postfix) with ESMTPSA id 4C62E40A626; Thu, 8 Nov 2018 08:35:28 -0800 (PST) Subject: Re: Support for VRF in NFS? To: "J. Bruce Fields" References: <20181108011429.GC30776@fieldses.org> <20181108153136.GA4947@fieldses.org> Cc: "linux-nfs@vger.kernel.org" From: Ben Greear Message-ID: <90f8e9ba-3953-e2d1-56f4-421a4991cef8@candelatech.com> Date: Thu, 8 Nov 2018 08:35:26 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20181108153136.GA4947@fieldses.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 11/08/2018 07:31 AM, J. Bruce Fields wrote: > On Wed, Nov 07, 2018 at 09:08:16PM -0800, Ben Greear wrote: >> >> >> On 11/07/2018 05:14 PM, J. Bruce Fields wrote: >>> On Tue, Nov 06, 2018 at 01:03:54PM -0800, Ben Greear wrote: >>>> Hello, >>>> >>>> I made a stab at implementing VRF support in NFS, but it appears >>>> fairly complicated and I ended up reverting my changes.... >>>> >>>> Is anyone working on this? >>>> >>>> And, if not, if anyone would like to be sponsored to work on this, please >>>> let me know. >>> >>> Um, sorry--what's VRF? >> >> Virtual Router logic. It is sort of like network stack containers, >> and has been solid and fully featured in the kernel since 4.16 or so. >> >> In the end, you effectively need to call the logic that SO_BINDTODEVICE >> calls on the socket before binding to an IP. >> >> The NFS and RPC logic is a giant tangled mess to my eyes, so >> hoping I could bribe someone else to do it :) > > So it's not enough to support network namespaces? > > What's your motivation for this? Network namespaces are difficult to uses for lots of use cases, and thus VRF was born. My own motivation is that it allows me to make hundreds or thousands of individual NFS mounts from local mac-vlan (or other virtual/physical interfaces), for testing purposes. Similar to my patch set that binds to local IP address, which gives similar feature set for non-VRF configurations. These bind-local-IP patches are not upstream and were rejected in the past as un-wanted. I'm hoping VRF support would be more acceptable. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com