On 2019-03-12 2:42 p.m., Serge Semin wrote:
> If you don't want to add a large semantic and infrastructure change at
> this point, then it would be better to leave NTB port API the way it is
> now, and use logical port indexes in the ntb_peer_resource_idx() method.
> You'd also need to use this
On Wed, Mar 06, 2019 at 04:22:33PM -0700, Logan Gunthorpe wrote:
>
> On 2019-03-06 3:45 p.m., Serge Semin wrote:
> [Snip]
>
> Pretty sure everything above is just agreement...
>
> > So your current approach is inbound MW-centralized, while mine is developed
> > around the outbound MWs.
>
> I do
On 2019-03-06 3:45 p.m., Serge Semin wrote:
[Snip]
Pretty sure everything above is just agreement...
> So your current approach is inbound MW-centralized, while mine is developed
> around the outbound MWs.
I don't think this has anything to do with inbound vs outbound. The
problem is the sa
On Wed, Mar 06, 2019 at 12:11:11PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-03-05 6:24 p.m., Serge Semin wrote:
> >> + * In a 5 peer system, this function will return the following matrix
> >> + *
> >> + * pidx \ port01234
> >> + * 0 00123
> >>
On 2019-03-05 6:24 p.m., Serge Semin wrote:
>> + * In a 5 peer system, this function will return the following matrix
>> + *
>> + * pidx \ port01234
>> + * 0 00123
>> + * 1 01234
>> + * 2 0123
On Wed, Feb 13, 2019 at 10:54:49AM -0700, Logan Gunthorpe wrote:
Hi
> When using multi-ports each port uses resources (dbs, msgs, mws, etc)
> on every other port. Creating a mapping for these resources such that
> each port has a corresponding resource on every other port is a bit
> tricky.
>
>
When using multi-ports each port uses resources (dbs, msgs, mws, etc)
on every other port. Creating a mapping for these resources such that
each port has a corresponding resource on every other port is a bit
tricky.
Introduce the ntb_peer_resource_idx() function for this purpose.
It returns the pe
