[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dm-devel
Subject:    Re: [dm-devel] dm-multipath - IO queue dispatch based on FPIN Congestion/Latency notifications.
From:       Martin Wilck <martin.wilck () suse ! com>
Date:       2021-03-31 12:41:06
Message-ID: 5a0f7c60adbad68fc1df91e1a6c192fab04b66fc.camel () suse ! com
[Download RAW message or body]

On Wed, 2021-03-31 at 17:27 +0530, Muneendra Kumar M wrote:
> Hi Martin,
> 
> > > 
> > > I'm aware of Ben's work, but I hadn't realized it had anything to
> > > do
> > > with FPIN. As of today, multipathd doesn't listen on the
> > > NETLINK_SCSITRANSPORT socket. Does any user space tool do this?
> > > Google didn't show me anything.
> > > 
> > I did, once, but that was years ago.
> 
> We have user space daemon(Broadcom'sFiber Channel Transport Daemon)
> called
> fctxpd (Benjamin was talking in his patch) which acts on fpin-li events
> by listening  on NETLINK_SCSITRANSPORT socket
> And it sets the path to marginal path group on receiving FPIN events.
> This daemon is part of epel8.
> Below is the path for the same where we have changes
> https://github.com/brocade/bsn-fc-txptd
> 
> Regards,
> Muneendra.

I see, and this daemon uses multipathd's "set marginal" command to make
multipathd act on it. I can see now that Ben talked about "Broadcom's
Fiber Channel Transport Daemon" back then, but he didn't go into
details, and I either overlooked it entirely, or forgot about it.
I recall that I was wondering by myself whether the "set marginal"
command had any use other than manual testing.

I wonder if we could / should incorporate this functionality into
multipathd itself.

But anyway, it seems that this part of the FPIN mechanism works
already.

Thanks
Martin

-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix Imendörffer



--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

[prev in list] [next in list] [prev in thread] [next in thread]