Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1702276

Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers

From Logan Gunthorpe <logang@deltatee.com>
Newsgroups linux.kernel
Subject Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers
Date 2017-08-02 19:10 +0200
Message-ID <ua5jH-4gE-3@gated-at.bofh.it> (permalink)
References (1 earlier) <u7ffz-82I-13@gated-at.bofh.it> <u9KRZ-82o-57@gated-at.bofh.it> <u9NPP-1sk-7@gated-at.bofh.it> <ua1zs-1Rq-17@gated-at.bofh.it> <ua4QF-3PO-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



On 02/08/17 10:32 AM, Jon Mason wrote:
> After a long-ish conversation on IRC, the way we want to go forward
> would be to provide 2 ways of communicating prior to the MW's being
> setup:  SPADs and Message Registers.  The HW driver would make
> available whichever ones are supported by the hardware.  The transport
> can see which of those are available in the HW driver, select the
> appropriate one, and use it to setup the NTB connection, MW, etc.
> similar to how the SPADs are being used today.  This would allow for
> any current clients to work unmodified, and would require minimal
> changes to the existing transport layer.

I'm open to this, but I have a couple points:

1) I think there needs to be an ntb library or similar so the client
just has to say "communicate this setup data to the peer X". We don't
need every client replicating the decision to use spads or msgs or whatever.

2) In my experience, message registers are a bit of a pain to send
chunks of data like is being done with spads in the existing clients.
(Some time ago, I originally tried emulating spads with message
registers and it did not work well.)  You can only send 32bits at a time
and you have to have a signal indicating the other side is finished with
it before sending another message. I think they are best used just for
signaling infrequent events where if you loose a message it's not an issue.

One thought I had was that maybe we need to just push this decision into
the drivers. ie if there's an ntb api just for communicating setup data,
the driver could then determine the most appropriate way to communicate
it for the hardware (whether via spads, messages or a special memory
window). However, the difficulty with this is that the driver would have
to communicate if it's using spad resources it would otherwise advertise
to the clients.

Though, maybe we don't need spads in the ntb api. Maybe they are the
wrong abstraction. All the existing clients only use them for setup
data, so if we dropped the spad api in favor of a setup data api, the
driver could then just make the decision on how best to communicate it.

Anyway, just my thoughts.

Logan

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers Jon Mason <jdmason@kudzu.us> - 2017-08-01 21:20 +0200
  Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers Logan Gunthorpe <logang@deltatee.com> - 2017-08-02 00:30 +0200
    RE: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers "Allen Hubbe" <Allen.Hubbe@dell.com> - 2017-08-02 15:10 +0200
      Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers Jon Mason <jdmason@kudzu.us> - 2017-08-02 18:40 +0200
        Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers Logan Gunthorpe <logang@deltatee.com> - 2017-08-02 19:10 +0200

csiph-web