Re: New NTB API Issue

On 23/06/17 04:06 PM, Allen Hubbe wrote: > From: Logan Gunthorpe >> But any translation can be >> programmed by any peer. > > That doesn't seem safe. Even though it can be done as you say, would it not > be better to have each specific translation under the control of exactly one > driver? >

Re: New NTB API Issue

On 23/06/17 04:06 PM, Allen Hubbe wrote: > From: Logan Gunthorpe >> But any translation can be >> programmed by any peer. > > That doesn't seem safe. Even though it can be done as you say, would it not > be better to have each specific translation under the control of exactly one > driver? >

RE: New NTB API Issue

From: Logan Gunthorpe > But any translation can be > programmed by any peer. That doesn't seem safe. Even though it can be done as you say, would it not be better to have each specific translation under the control of exactly one driver? If drivers can reach across and set the translation of

RE: New NTB API Issue

From: Logan Gunthorpe > But any translation can be > programmed by any peer. That doesn't seem safe. Even though it can be done as you say, would it not be better to have each specific translation under the control of exactly one driver? If drivers can reach across and set the translation of

RE: New NTB API Issue

From: Logan Gunthorpe > Hey, > > Thanks Serge for the detailed explanation. This is pretty much exactly > as I had thought it should be interpreted. My only problem remains that > my hardware can't provide ntb_mw_get_align until the port it is asking > about has configured itself. The easiest way

RE: New NTB API Issue

From: Logan Gunthorpe > Hey, > > Thanks Serge for the detailed explanation. This is pretty much exactly > as I had thought it should be interpreted. My only problem remains that > my hardware can't provide ntb_mw_get_align until the port it is asking > about has configured itself. The easiest way

Re: New NTB API Issue

Hey, Thanks Serge for the detailed explanation. This is pretty much exactly as I had thought it should be interpreted. My only problem remains that my hardware can't provide ntb_mw_get_align until the port it is asking about has configured itself. The easiest way to solve this is to only allow

Re: New NTB API Issue

Hey, Thanks Serge for the detailed explanation. This is pretty much exactly as I had thought it should be interpreted. My only problem remains that my hardware can't provide ntb_mw_get_align until the port it is asking about has configured itself. The easiest way to solve this is to only allow

Re: New NTB API Issue

On Fri, Jun 23, 2017 at 03:07:19PM -0400, Allen Hubbe wrote: Hello Allen, > From: Logan Gunthorpe > > 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

Re: New NTB API Issue

On Fri, Jun 23, 2017 at 03:07:19PM -0400, Allen Hubbe wrote: Hello Allen, > From: Logan Gunthorpe > > 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: > > > >

Re: New NTB API Issue

On 23/06/17 01:07 PM, Allen Hubbe wrote: > The client's haven't been fully ported to the multi-port api yet. They were > only minimally changed to call the new api, but so far other than that they > have only been made to work as they had before. So is it intended to eventually send the

Re: New NTB API Issue

On 23/06/17 01:07 PM, Allen Hubbe wrote: > The client's haven't been fully ported to the multi-port api yet. They were > only minimally changed to call the new api, but so far other than that they > have only been made to work as they had before. So is it intended to eventually send the

RE: New NTB API Issue

From: Logan Gunthorpe > 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

RE: New NTB API Issue

From: Logan Gunthorpe > 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

Re: New NTB API Issue

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

Re: New NTB API Issue

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

RE: New NTB API Issue

From: Logan Gunthorpe > On 6/22/2017 4:42 PM, Allen Hubbe wrote: > > From: Logan Gunthorpe > >> Any thoughts on changing the semantics of mw_get_align so it must be > >> called with the link up? > > > > The intention of these is that these calls return information from the > > local port. The

RE: New NTB API Issue

From: Logan Gunthorpe > On 6/22/2017 4:42 PM, Allen Hubbe wrote: > > From: Logan Gunthorpe > >> Any thoughts on changing the semantics of mw_get_align so it must be > >> called with the link up? > > > > The intention of these is that these calls return information from the > > local port. The

Re: New NTB API Issue

On 6/22/2017 4:42 PM, Allen Hubbe wrote: From: Logan Gunthorpe Any thoughts on changing the semantics of mw_get_align so it must be called with the link up? The intention of these is that these calls return information from the local port. The calls themselves don't reach across the link to

Re: New NTB API Issue

On 6/22/2017 4:42 PM, Allen Hubbe wrote: From: Logan Gunthorpe Any thoughts on changing the semantics of mw_get_align so it must be called with the link up? The intention of these is that these calls return information from the local port. The calls themselves don't reach across the link to

RE: New NTB API Issue

From: Logan Gunthorpe > Any thoughts on changing the semantics of mw_get_align so it must be > called with the link up? The intention of these is that these calls return information from the local port. The calls themselves don't reach across the link to the peer, but the information returned

RE: New NTB API Issue

From: Logan Gunthorpe > Any thoughts on changing the semantics of mw_get_align so it must be > called with the link up? The intention of these is that these calls return information from the local port. The calls themselves don't reach across the link to the peer, but the information returned

Re: New NTB API Issue

On 6/22/2017 4:12 PM, Allen Hubbe wrote: The resource size given by peer_mw_get_addr might be different than the max_size given by ntb_mw_get_align. I am most familiar with the ntb_hw_intel driver and that type of ntb hardware. The peer_mw_get_addr size is of the primary bar on the side to

Re: New NTB API Issue

On 6/22/2017 4:12 PM, Allen Hubbe wrote: The resource size given by peer_mw_get_addr might be different than the max_size given by ntb_mw_get_align. I am most familiar with the ntb_hw_intel driver and that type of ntb hardware. The peer_mw_get_addr size is of the primary bar on the side to

RE: New NTB API Issue

From: Logan Gunthorpe > On 6/22/2017 12:32 PM, Allen Hubbe wrote: > > From: Logan Gunthorpe > >> 2) The changes to the Intel and AMD driver for mw_get_align sets > >> *max_size to the local pci resource size. (Thus making the assumption > >> that the local is the same as the peer, which is wrong).

RE: New NTB API Issue

From: Logan Gunthorpe > On 6/22/2017 12:32 PM, Allen Hubbe wrote: > > From: Logan Gunthorpe > >> 2) The changes to the Intel and AMD driver for mw_get_align sets > >> *max_size to the local pci resource size. (Thus making the assumption > >> that the local is the same as the peer, which is wrong).

RE: New NTB API Issue

From: Logan Gunthorpe > Hey Guys, > > I've run into some subtle issues with the new API: > > It has to do with splitting mw_get_range into mw_get_align and > peer_mw_get_addr. > > The original mw_get_range returned the size of the /local/ memory > window's size, address and alignment

RE: New NTB API Issue

From: Logan Gunthorpe > Hey Guys, > > I've run into some subtle issues with the new API: > > It has to do with splitting mw_get_range into mw_get_align and > peer_mw_get_addr. > > The original mw_get_range returned the size of the /local/ memory > window's size, address and alignment

Re: New NTB API Issue

On 6/22/2017 12:32 PM, Allen Hubbe wrote: From: Logan Gunthorpe Hey Guys, I've run into some subtle issues with the new API: It has to do with splitting mw_get_range into mw_get_align and peer_mw_get_addr. The original mw_get_range returned the size of the /local/ memory window's size,

Re: New NTB API Issue

On 6/22/2017 12:32 PM, Allen Hubbe wrote: From: Logan Gunthorpe Hey Guys, I've run into some subtle issues with the new API: It has to do with splitting mw_get_range into mw_get_align and peer_mw_get_addr. The original mw_get_range returned the size of the /local/ memory window's size,

New NTB API Issue

Hey Guys, I've run into some subtle issues with the new API: It has to do with splitting mw_get_range into mw_get_align and peer_mw_get_addr. The original mw_get_range returned the size of the /local/ memory window's size, address and alignment requirements. The ntb clients then take the local

New NTB API Issue

Hey Guys, I've run into some subtle issues with the new API: It has to do with splitting mw_get_range into mw_get_align and peer_mw_get_addr. The original mw_get_range returned the size of the /local/ memory window's size, address and alignment requirements. The ntb clients then take the local