[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4d932597-3592-2ce1-5a5f-cb5ba36a3a93@deltatee.com>
Date: Thu, 22 Jun 2017 16:49:16 -0600
From: Logan Gunthorpe <logang@...tatee.com>
To: Allen Hubbe <Allen.Hubbe@...l.com>, 'Jon Mason' <jdmason@...zu.us>
Cc: linux-ntb@...glegroups.com, linux-kernel@...r.kernel.org,
'Dave Jiang' <dave.jiang@...el.com>,
'Serge Semin' <fancer.lancer@...il.com>,
'Kurt Schwemmer' <kurt.schwemmer@...rosemi.com>,
'Stephen Bates' <sbates@...thlin.com>,
'Greg Kroah-Hartman' <gregkh@...uxfoundation.org>
Subject: Re: New NTB API Issue
On 6/22/2017 4:42 PM, Allen Hubbe wrote:
> From: Logan Gunthorpe
>> Any thoughts on changing the semantics of mw_get_align so it must be
>> called with the link up?
>
> The intention of these is that these calls return information from the local port. The calls themselves don't reach across the link to the peer, but the information returned from the local port needs to be communicated for setting up the translation end-to-end.
Ok, well if it's from the local port, then splitting up mw_get_range
into peer_mw_get_addr and mw_get_align is confusing because one has the
peer designation and the other doesn't. And all the clients apply the
alignments to the remote bar so they'd technically need to transfer them
across the link somehow.
> I would like to understand why this hardware needs link up. Are there registers on the local port that are only valid after link up?
We only need the link up if we are trying to find the alignment
requirements (and max_size) of the peer's bar. In theory, switchtec
could have different sizes of bars on both sides of the link and
different alignment requirements. Though, in practice, this is probably
unlikely.
> Can you post snippets of how ntb_mw_get_align and ntb_peer_mw_get_addr might be implemented for the Switchtec?
Hmm, yes, but lets sort out my confusion on the semantics per above first.
Logan
Powered by blists - more mailing lists