From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5208953374455055913==" MIME-Version: 1.0 From: Walker, Benjamin Subject: Re: [SPDK] Change in ...spdk[master]: Initial checkin of the multipath vbdev driver. Date: Fri, 15 Feb 2019 21:33:58 +0000 Message-ID: <965f7f6ff56430f4f255bbb7e6916e2c1b4cd154.camel@intel.com> In-Reply-To: CANvN+emzBob_pOF5+8QiC4kRo2k20QhKoFcuQ5_vL8+BVVbH1Q@mail.gmail.com List-ID: To: spdk@lists.01.org --===============5208953374455055913== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, 2019-02-15 at 19:48 +0300, Andrey Kuzmin wrote: > Ben, > = > you had indicated that you'd like to have a discussion of the multipath > driver. Let me know what you think. I haven't had a chance to through the actual implementation of the patch, b= ut multipathing in general is certainly of interest and warrants inclusion in = SPDK. I'd love to move ahead on this. The big challenge is figuring out the best place to implement it. There are= at least 3 different options that I see. 1) Implement it as a bdev module. When the module gets a claim callback, it checks to see if the new bdev is simply a different path to an existing bdev (using some mechanism that isn't defined yet?) and then claims them both and exposes a single bdev to the upper layer. 2) Implement it in the generic bdev code so that each individual bdev modul= e can call some function to add additional paths to a given bdev. 3) Implement it inside the nvme driver. There are a number of really cool features for multipathing in NVMe (ANA and such) that don't translate well = to a generic bdev. The only way to take advantage of some of these might be to a= dd support directly into the nvme driver. It could be that we end up doing a combination of 1 or 2 with number 3 as w= ell. I'd love some other opinions here from interested parties. > = > Thanks, > Andrey > = > On Fri, Feb 1, 2019, 21:12 Andrey Kuzmin = > > I will appreciate an input on if the bdev-level multipathing is of > > general interest and is worth inclusion. On positive determination I > > can find time to rebase and resubmit. > > = > > Notice also that, in this case, decoupling open in write mode from > > claims patch (https://review.gerrithub.io/c/spdk/spdk/+/422177) should > > be revisited and included, as otherwise implementing multiple paths to > > the same base bdev as path bdevs is rather problematic (as this > > obviously involves multiple writers). > > = > > Thanks, > > Andrey > > = > = > _______________________________________________ > SPDK mailing list > SPDK(a)lists.01.org > https://lists.01.org/mailman/listinfo/spdk --===============5208953374455055913==--