From: Logan Gunthorpe <logang@deltatee.com>
To: Allen Hubbe <Allen.Hubbe@dell.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 10:51:03 -0600 [thread overview]
Message-ID: <5aa9c438-e152-4caa-2c6d-cbbd130a0eb2@deltatee.com> (raw)
In-Reply-To: <000001d2ec23$2bd9f300$838dd900$@dell.com>
On 23/06/17 07:18 AM, Allen Hubbe wrote:
> By "remote" do you mean the source or destination of a write?
Look at how these calls are used in ntb_transport and ntb_perf:
They both call ntb_peer_mw_get_addr to get the size of the BAR. The size
is sent via spads to the other side. The other side then uses
ntb_mw_get_align and applies align_size to the received size.
> Yes, clients should transfer the address and size information to the peer.
But then they also need to technically transfer the alignment
information as well. Which neither of the clients do.
> 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.
I like the rule that these api calls are not to reach across the port.
But then API looks very wrong. Why are we calling one peer_mw_get addr
and the other mw_get_align? And why does mw_get_align have a peer index?
> Some snippets of code would help me understand your interpretation of the api semantics more exactly.
I'm not sure the code to best show this in code, but let me try
describing an example situation:
Lets say we have the following mws on each side (this is something that
is possible with Switchtec hardware):
Host A BARs:
mwA0: 2MB size, aligned to 4k, size aligned to 4k
mwA1: 4MB size, aligned to 4k, size aligned to 4k
mwA2: 64k size, aligned to 64k, size aligned to 64k
Host B BARs:
mwB0: 2MB size, aligned to 4k, size aligned to 4k
mwB1: 64k size, aligned to 64k, size aligned to 64k
So on Host A: peer_mw_get_addr(idx=1) should return size=4M (from mwA1),
but it's not clear what mw_get_align(widx=1) should do. I see two
possibilities:
1) Given that it has the opposite sense of peer_mw_get_addr (ie. there
is no peer in it's name) and that this new api also has a peer index, it
should return align_size=64k (from mwB1). However, in order to do this,
Host B must be fully configured (technically the link doesn't have to be
fully up, but having a link up is the only way for a client to tell if
Host B is configured or not).
2) Given your assertion that these APIs should never reach across the
link, then one could say it should return align_size=4k. However, in
this situation the name is really confusing. And the fact that it has a
pidx argument makes no sense. And the way ntb_transport and ntb_perf use
it is wrong because they will end up masking the 64K size of mwB1 with
the 4k align_size from mwA1.
Does that make more sense?
Thanks,
Logan
next prev parent reply other threads:[~2017-06-23 16:51 UTC|newest]
Thread overview: 57+ 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 14:09 ` Logan Gunthorpe
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 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 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:40 ` Logan Gunthorpe
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:49 ` Logan Gunthorpe
2017-06-23 13:18 ` Allen Hubbe
2017-06-23 16:51 ` Logan Gunthorpe [this message]
2017-06-23 19:07 ` Allen Hubbe
2017-06-23 20:39 ` Logan Gunthorpe
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:59 ` Logan Gunthorpe
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=5aa9c438-e152-4caa-2c6d-cbbd130a0eb2@deltatee.com \
--to=logang@deltatee.com \
--cc=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=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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome