From mboxrd@z Thu Jan 1 00:00:00 1970 From: Muneendra Kumar M Subject: Pushing the multipath state info into the fabric Date: Thu, 26 Oct 2017 10:18:34 +0000 Message-ID: <003dec9a190f45aa91bff7e0010968e1@BRMWP-EXMB12.corp.brocade.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5582541216918491775==" Return-path: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: "dm-devel@redhat.com" List-Id: dm-devel.ids --===============5582541216918491775== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_003dec9a190f45aa91bff7e0010968e1BRMWPEXMB12corpbrocadec_" --_000_003dec9a190f45aa91bff7e0010968e1BRMWPEXMB12corpbrocadec_ Content-Type: text/plain; charset="us-ascii" Hi , We are working on the SAN fabric side to collect and present the multipath status information to the SAN administrators. So, I am looking forward to push the multipath state information to the fabric in the form of CT (Common Transport) frames, by using the libhba APIs. Since the multipath daemon is already keeping track of the multipath device and state info, I feel that it is the correct place to add the code to push the info to the fabric. Please kindly let me know your thoughts on this. Regards, Muneendra. --_000_003dec9a190f45aa91bff7e0010968e1BRMWPEXMB12corpbrocadec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ,

 =

We are working on the SA= N fabric side to collect and present the multipath status information to th= e SAN administrators.

So, I am looking forward= to push the multipath state information to the fabric in the form of CT (C= ommon Transport) frames, by using the libhba APIs.

Since the multipath daem= on is already keeping track of the multipath device and state info, I feel = that it is the correct place to add the code to push the info to the fabric= .

Please kindly let me kno= w your thoughts on this.

 =

 =

Regards,

Muneendra.

--_000_003dec9a190f45aa91bff7e0010968e1BRMWPEXMB12corpbrocadec_-- --===============5582541216918491775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5582541216918491775==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: Pushing the multipath state info into the fabric Date: Thu, 26 Oct 2017 10:35:32 -0400 Message-ID: <20171026143532.GA5490@redhat.com> References: <003dec9a190f45aa91bff7e0010968e1@BRMWP-EXMB12.corp.brocade.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <003dec9a190f45aa91bff7e0010968e1@BRMWP-EXMB12.corp.brocade.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Muneendra Kumar M Cc: "dm-devel@redhat.com" List-Id: dm-devel.ids On Thu, Oct 26 2017 at 6:18am -0400, Muneendra Kumar M wrote: > Hi , > > > > We are working on the SAN fabric side to collect and present the multipath > status information to the SAN administrators. > > So, I am looking forward to push the multipath state information to the > fabric in the form of CT (Common Transport) frames, by using the libhba > APIs. > > Since the multipath daemon is already keeping track of the multipath > device and state info, I feel that it is the correct place to add the code > to push the info to the fabric. > > Please kindly let me know your thoughts on this. Sounds like you'd probably want to expose APIs that enable you to access the state you require from multipathd rather than train multipathd to inject anything into the fabric. But that is just my initial take. Mike From mboxrd@z Thu Jan 1 00:00:00 1970 From: Muneendra Kumar M Subject: Re: Pushing the multipath state info into the fabric Date: Mon, 30 Oct 2017 04:40:53 +0000 Message-ID: <9a527555006647c6b4586fe78cf6d7b1@BRMWP-EXMB12.corp.brocade.com> References: <003dec9a190f45aa91bff7e0010968e1@BRMWP-EXMB12.corp.brocade.com> <20171026143532.GA5490@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171026143532.GA5490@redhat.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mike Snitzer Cc: "dm-devel@redhat.com" List-Id: dm-devel.ids Hi Mike, Our intention is to train the multipathd for pushing the multipath info into the fabric using LIBHBA api's. Can we call libhba apis in multipathd to push the info into fabric? Regards, Muneendra. -----Original Message----- From: Mike Snitzer [mailto:snitzer@redhat.com] Sent: Thursday, October 26, 2017 8:06 PM To: Muneendra Kumar M Cc: dm-devel@redhat.com Subject: Re: Pushing the multipath state info into the fabric On Thu, Oct 26 2017 at 6:18am -0400, Muneendra Kumar M wrote: > Hi , > > > > We are working on the SAN fabric side to collect and present the multipath > status information to the SAN administrators. > > So, I am looking forward to push the multipath state information to the > fabric in the form of CT (Common Transport) frames, by using the libhba > APIs. > > Since the multipath daemon is already keeping track of the multipath > device and state info, I feel that it is the correct place to add the code > to push the info to the fabric. > > Please kindly let me know your thoughts on this. Sounds like you'd probably want to expose APIs that enable you to access the state you require from multipathd rather than train multipathd to inject anything into the fabric. But that is just my initial take. Mike From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: Pushing the multipath state info into the fabric Date: Mon, 30 Oct 2017 15:17:22 -0400 Message-ID: <20171030191722.GA13837@redhat.com> References: <003dec9a190f45aa91bff7e0010968e1@BRMWP-EXMB12.corp.brocade.com> <20171026143532.GA5490@redhat.com> <9a527555006647c6b4586fe78cf6d7b1@BRMWP-EXMB12.corp.brocade.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <9a527555006647c6b4586fe78cf6d7b1@BRMWP-EXMB12.corp.brocade.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Muneendra Kumar M Cc: Todd Gill , "dm-devel@redhat.com" , Gris Ge List-Id: dm-devel.ids (please don't top-post once someone establishes bottom-posting) On Mon, Oct 30 2017 at 12:40am -0400, Muneendra Kumar M wrote: > Hi Mike, > Our intention is to train the multipathd for pushing the multipath > info into the fabric using LIBHBA api's. > Can we call libhba apis in multipathd to push the info into fabric? I'll defer to others who maintain and develop multipathd but I'll say that I think it'd be more logical/correct to _not_ code multipathd to do this directly. But rather have your own code that interfaces with multipathd to get the multipath info and push it where you'd like. Newer multipathd code that was added to make programmatic access to multipathd state easier/possible includes: 1) multipathd show maps json multipathd show map $map json 2) Use libdmmp (see multipath-tools commit 4335abb36f33f1). libdmmp provides access to the json output via C api. (thanks to Todd and Gris for providing pointers to these interfaces) Mike