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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Aug 2017 12:32:24 -0400
From:   Jon Mason <jdmason@...zu.us>
To:     Allen Hubbe <Allen.Hubbe@...l.com>
Cc:     Logan Gunthorpe <logang@...tatee.com>, linux-ntb@...glegroups.com,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Dave Jiang <dave.jiang@...el.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kurt Schwemmer <kurt.schwemmer@...rosemi.com>,
        Stephen Bates <sbates@...thlin.com>,
        Serge Semin <fancer.lancer@...il.com>
Subject: Re: [PATCH v3 14/16] switchtec_ntb: implement scratchpad registers

On Wed, Aug 2, 2017 at 9:06 AM, Allen Hubbe <Allen.Hubbe@...l.com> wrote:
> From: Logan Gunthorpe
>> On 01/08/17 01:10 PM, Jon Mason wrote:
>> > It would probaly be better if I remarked about the SPADs in the actual
>> > patch about the SPADS :)
>> >
>> > The whole point of using the SPADs in the NTB driver was to workaround
>> > the problems establishing a connection between the two sides of the
>> > NTB and where everything lives.  So, using a MW to get around the
>> > SPADs is sort of backwards (and slightly funny).  I realize you are
>> > trying to use the existing transport with minimal changes to enable
>> > your hardware, and thus this makes logical sense to you.  However, if
>> > the SPADs are not really needed, then we should either remove them
>> > from the transport (or use them for something else).
>> >
>> > Per my comment in the other patch, I'm amenable to take this series
>> > as-is, assuming you are willing to address this design issue in the
>> > near future.  Thoughts?
>>
>> Yes, I agree. I'd be willing to help but it seems the clients are
>> written the way they are for the other drivers, so it's their needs
>> (which I'm not fully aware of) that have to be considered.
>
> The proposed change, removing use of spads from transport, would not affect ntrdma.

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.

Since this is outside the scope of this series, per my email yesterday
allowing the SPAD workaround, we should start up another thread on the
NTB mailing list and flesh out the details and any benefits/drawbacks.
Then we, as a community, can make the changes necessary to the drivers
and transport to get this working more optimally.

Thanks,
Jon

>> I've also made all the other changes you sent as well as the file rename
>> Dave requested. Once I see the bug fix patch you were going to pull hit
>> ntb-next I'll rebase, test and resubmit.
>>
>> Thanks,
>>
>> Logan
>