From: "Allen Hubbe" <Allen.Hubbe@dell.com> To: "'Logan Gunthorpe'" <logang@deltatee.com>, "'Jon Mason'" <jdmason@kudzu.us> Cc: <linux-ntb@googlegroups.com>, <linux-kernel@vger.kernel.org>, "'Dave Jiang'" <dave.jiang@intel.com>, "'Serge Semin'" <fancer.lancer@gmail.com>, "'Kurt Schwemmer'" <kurt.schwemmer@microsemi.com>, "'Stephen Bates'" <sbates@raithlin.com>, "'Greg Kroah-Hartman'" <gregkh@linuxfoundation.org> Subject: RE: New NTB API Issue Date: Fri, 23 Jun 2017 09:18:12 -0400 [thread overview] Message-ID: <000001d2ec23$2bd9f300$838dd900$@dell.com> (raw) In-Reply-To: <4d932597-3592-2ce1-5a5f-cb5ba36a3a93@deltatee.com> From: Logan Gunthorpe > 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. By "remote" do you mean the source or destination of a write? Yes, clients should transfer the address and size information to the peer. > > 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 Maybe this is the confusion. None of these api calls are to reach across to the peer port, as to get the size of the peer's bar. They are to get information from the local port, or to configure the local port. Some mw configuration is done at the destination, as for Intel and AMD, and some configuration is done on the source side, for IDT. The local configuration of the port on one side could depend on information from the remote port on the other side. For example in IDT, the mw translation configured on the source side needs to know destination address information. Likewise, if there is any difference in the size of the range that can be translated by ports on opposing sides, that needs to be negotiated. > 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. Some snippets of code would help me understand your interpretation of the api semantics more exactly. > Logan
WARNING: multiple messages have this Message-ID (diff)
From: "Allen Hubbe" <Allen.Hubbe@dell.com> To: 'Logan Gunthorpe' <logang@deltatee.com>, 'Jon Mason' <jdmason@kudzu.us> Cc: linux-ntb@googlegroups.com, linux-kernel@vger.kernel.org, 'Dave Jiang' <dave.jiang@intel.com>, 'Serge Semin' <fancer.lancer@gmail.com>, 'Kurt Schwemmer' <kurt.schwemmer@microsemi.com>, 'Stephen Bates' <sbates@raithlin.com>, 'Greg Kroah-Hartman' <gregkh@linuxfoundation.org> Subject: RE: New NTB API Issue Date: Fri, 23 Jun 2017 09:18:12 -0400 [thread overview] Message-ID: <000001d2ec23$2bd9f300$838dd900$@dell.com> (raw) In-Reply-To: <4d932597-3592-2ce1-5a5f-cb5ba36a3a93@deltatee.com> From: Logan Gunthorpe > 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. By "remote" do you mean the source or destination of a write? Yes, clients should transfer the address and size information to the peer. > > 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 Maybe this is the confusion. None of these api calls are to reach across to the peer port, as to get the size of the peer's bar. They are to get information from the local port, or to configure the local port. Some mw configuration is done at the destination, as for Intel and AMD, and some configuration is done on the source side, for IDT. The local configuration of the port on one side could depend on information from the remote port on the other side. For example in IDT, the mw translation configured on the source side needs to know destination address information. Likewise, if there is any difference in the size of the range that can be translated by ports on opposing sides, that needs to be negotiated. > 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. Some snippets of code would help me understand your interpretation of the api semantics more exactly. > Logan
next prev parent reply other threads:[~2017-06-23 13:18 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-15 20:37 [RFC PATCH 00/13] Switchtec NTB Support Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 01/13] switchtec: move structure definitions into a common header Logan Gunthorpe 2017-06-17 5:11 ` Greg Kroah-Hartman 2017-06-15 20:37 ` [RFC PATCH 02/13] switchtec: export class symbol for use in upper layer driver Logan Gunthorpe 2017-06-17 5:11 ` Greg Kroah-Hartman 2017-06-17 16:16 ` Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 03/13] switchtec: add ntb hardware register definitions Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 04/13] switchtec: add link event notifier block Logan Gunthorpe 2017-06-17 5:14 ` Greg Kroah-Hartman 2017-06-17 16:20 ` Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 05/13] switchtec_ntb: introduce initial ntb driver Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 06/13] switchtec_ntb: initialize hardware for memory windows Logan Gunthorpe 2017-06-17 5:16 ` Greg Kroah-Hartman 2017-06-17 16:39 ` Logan Gunthorpe 2017-06-18 0:33 ` Greg Kroah-Hartman 2017-06-15 20:37 ` [RFC PATCH 07/13] switchtec_ntb: initialize hardware for doorbells and messages Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 08/13] switchtec_ntb: add skeleton ntb driver Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 09/13] switchtec_ntb: add link management Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 10/13] switchtec_ntb: implement doorbell registers Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 11/13] switchtec_ntb: implement scratchpad registers Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 12/13] switchtec_ntb: add memory window support Logan Gunthorpe 2017-06-15 20:37 ` [RFC PATCH 13/13] switchtec_ntb: update switchtec documentation with notes for ntb Logan Gunthorpe 2017-06-16 13:53 ` [RFC PATCH 00/13] Switchtec NTB Support Allen Hubbe 2017-06-16 13:53 ` Allen Hubbe 2017-06-16 13:53 ` Allen Hubbe 2017-06-16 14:09 ` Logan Gunthorpe 2017-06-16 15:34 ` Allen Hubbe 2017-06-16 15:34 ` Allen Hubbe 2017-06-16 15:34 ` Allen Hubbe 2017-06-16 16:47 ` Logan Gunthorpe 2017-06-16 17:39 ` Serge Semin 2017-06-16 18:08 ` Allen Hubbe 2017-06-16 18:08 ` Allen Hubbe 2017-06-16 18:08 ` Allen Hubbe 2017-06-16 19:17 ` Logan Gunthorpe 2017-06-16 16:33 ` Serge Semin 2017-06-16 17:08 ` Logan Gunthorpe 2017-06-16 18:38 ` Serge Semin 2017-06-16 18:38 ` Serge Semin 2017-06-16 19:34 ` Logan Gunthorpe 2017-06-16 20:21 ` Serge Semin 2017-06-17 5:09 ` 'Greg Kroah-Hartman' 2017-06-17 16:11 ` Logan Gunthorpe 2017-06-17 16:15 ` Logan Gunthorpe 2017-06-19 19:14 ` Jon Mason 2017-06-19 20:07 ` Jon Mason 2017-06-19 20:27 ` Logan Gunthorpe 2017-06-19 21:09 ` Jon Mason 2017-06-22 16:17 ` New NTB API Issue Logan Gunthorpe 2017-06-22 18:32 ` Allen Hubbe 2017-06-22 18:32 ` Allen Hubbe 2017-06-22 18:40 ` Logan Gunthorpe 2017-06-22 22:12 ` Allen Hubbe 2017-06-22 22:12 ` Allen Hubbe 2017-06-22 22:19 ` Logan Gunthorpe 2017-06-22 22:42 ` Allen Hubbe 2017-06-22 22:42 ` Allen Hubbe 2017-06-22 22:49 ` Logan Gunthorpe 2017-06-23 13:18 ` Allen Hubbe [this message] 2017-06-23 13:18 ` Allen Hubbe 2017-06-23 16:51 ` Logan Gunthorpe 2017-06-23 19:07 ` Allen Hubbe 2017-06-23 19:07 ` Allen Hubbe 2017-06-23 20:39 ` Logan Gunthorpe 2017-06-23 22:06 ` Allen Hubbe 2017-06-23 22:06 ` Allen Hubbe 2017-06-23 23:06 ` Logan Gunthorpe 2017-06-23 21:47 ` Serge Semin 2017-06-23 21:47 ` Serge Semin 2017-06-23 21:59 ` Logan Gunthorpe 2017-06-23 22:01 ` Allen Hubbe 2017-06-23 22:01 ` Allen Hubbe
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='000001d2ec23$2bd9f300$838dd900$@dell.com' \ --to=allen.hubbe@dell.com \ --cc=dave.jiang@intel.com \ --cc=fancer.lancer@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=jdmason@kudzu.us \ --cc=kurt.schwemmer@microsemi.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-ntb@googlegroups.com \ --cc=logang@deltatee.com \ --cc=sbates@raithlin.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.