Thread (26 messages) 26 messages, 7 authors, 2012-08-02

Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support

flat view

From: Jon Mason <hidden>
Date: 2012-07-31 16:33:13
Also in: linux-pci, lkml

On Tue, Jul 31, 2012 at 11:35:33AM +0800, Jianbin Kang wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help