From: Jon Mason <jon.mason@intel.com>
To: Jianbin Kang <kjbmail@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, Dave Jiang <dave.jiang@intel.com>
Subject: Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
Date: Tue, 31 Jul 2012 09:33:08 -0700 [thread overview]
Message-ID: <20120731163308.GA13610@jonmason-lab> (raw)
In-Reply-To: <CAF8raN6M0_TWyCCzjyXZcFYP=vgFaqQg4hNmNpBxSM+D0C_Bpg@mail.gmail.com>
On Tue, Jul 31, 2012 at 11:35:33AM +0800, Jianbin Kang wrote:
> > I've tried to make it all generic enough that non-Intel NTBs should plug in with
> > minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> > redesign of ntb_hw.c might be necessary. But from what I've seen of other
> > designs on the internet, they appear to be extremely similar. The transport and
> > client drivers were written with the hardware abstracted away as much as
> > possible to prevent the need to modify it for different hardware. If there is
> > anything which is Intel hardware specific, I'd be happy to change it to make it
> > more generic.
> In ntb_process_tx(), ntb uses hard-coding 'memcpy_toio' to copy data
> to remote.
> Is it better to provide a function pointer like 'tx()' and call qp->tx().
> memcpy_toio is a slow operation. Some hardware can setup a dma
> transfer and wait.
>
> IMHO, the best way is to handle tx in async mode. But it requires
> lots of modification.
Actually this is what I'm working on now, using async_tx to replace the
memcpy. I believe the changes shouldn't be that significant.
Is the "hardware that can setup dma" you refer to something that does
not use this interface?
Thanks,
Jon
next prev parent reply other threads:[~2012-07-31 16:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-30 0:26 [RFC v2 0/2] PCI-Express Non-Transparent Bridge Support Jon Mason
2012-07-30 0:26 ` [RFC v2 1/2] " Jon Mason
2012-07-30 16:50 ` Bjorn Helgaas
2012-07-30 18:15 ` Jon Mason
2012-07-31 3:35 ` Jianbin Kang
2012-07-31 16:33 ` Jon Mason [this message]
2012-08-01 2:10 ` Jianbin Kang
2012-08-01 2:18 ` Jiang, Dave
2012-07-31 13:45 ` Bjorn Helgaas
2012-07-31 16:02 ` chetan loke
2012-07-31 17:03 ` Bjorn Helgaas
2012-07-31 17:27 ` Jon Mason
2012-07-31 18:02 ` chetan loke
2012-08-02 1:43 ` Jon Mason
2012-07-31 17:10 ` Jon Mason
2012-07-31 16:14 ` chetan loke
2012-07-31 22:23 ` Greg KH
2012-07-31 22:51 ` Jon Mason
2012-07-31 23:14 ` Greg KH
2012-07-31 22:25 ` Greg KH
2012-08-02 1:49 ` Jon Mason
2012-07-30 0:26 ` [RFC v2 2/2] net: Add support for NTB virtual ethernet device Jon Mason
2012-07-30 14:02 ` Jiri Pirko
2012-07-30 18:19 ` Jon Mason
2012-07-30 20:09 ` Jiri Pirko
2012-07-31 22:28 ` Greg KH
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=20120731163308.GA13610@jonmason-lab \
--to=jon.mason@intel.com \
--cc=bhelgaas@google.com \
--cc=dave.jiang@intel.com \
--cc=kjbmail@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).