> On 1 May 2018, at 06:38, jackm wrote:
>
> On Mon, 30 Apr 2018 13:10:49 -0400
> Doug Ledford wrote:
>
> Looks good!
Yes, absolutely!
Håkon
>
> -Jack
>
>> On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
>>> On Mon, Apr 23, 2018 at
> On 1 May 2018, at 06:38, jackm wrote:
>
> On Mon, 30 Apr 2018 13:10:49 -0400
> Doug Ledford wrote:
>
> Looks good!
Yes, absolutely!
Håkon
>
> -Jack
>
>> On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
>>> On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
>>>
>>
On Mon, 30 Apr 2018 13:10:49 -0400
Doug Ledford wrote:
Looks good!
-Jack
> On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
> > On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
> >
> > > > > TIDs need to be globally unique on the entire machine.
> > >
On Mon, 30 Apr 2018 13:10:49 -0400
Doug Ledford wrote:
Looks good!
-Jack
> On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
> > On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
> >
> > > > > TIDs need to be globally unique on the entire machine.
> > > Jason, that is not
On Mon, Apr 30, 2018 at 01:10:49PM -0400, Doug Ledford wrote:
> On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
> > On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
> >
> > > > > TIDs need to be globally unique on the entire machine.
> > > Jason, that is not exactly correct.
> >
On Mon, Apr 30, 2018 at 01:10:49PM -0400, Doug Ledford wrote:
> On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
> > On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
> >
> > > > > TIDs need to be globally unique on the entire machine.
> > > Jason, that is not exactly correct.
> >
Hiatt, Don
> <don.hi...@intel.com>; Dasaratharaman Chandramouli
> <dasaratharaman.chandramo...@intel.com>; Weiny, Ira <ira.we...@intel.com>;
> Hefty, Sean <sean.he...@intel.com>; OFED mailing list r...@vger.kernel.org>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH
n ; OFED mailing list r...@vger.kernel.org>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] IB/core: Make ib_mad_client_id atomic
>
> On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
> > On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
> >
> > >
On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
> On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
>
> > > > TIDs need to be globally unique on the entire machine.
> > Jason, that is not exactly correct.
>
> The expecation for /dev/umad users is that they all receive locally
>
On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote:
> On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
>
> > > > TIDs need to be globally unique on the entire machine.
> > Jason, that is not exactly correct.
>
> The expecation for /dev/umad users is that they all receive locally
>
On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
> > > TIDs need to be globally unique on the entire machine.
> Jason, that is not exactly correct.
The expecation for /dev/umad users is that they all receive locally
unique TID prefixes. The kernel may be OK to keep things port-specific
On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote:
> > > TIDs need to be globally unique on the entire machine.
> Jason, that is not exactly correct.
The expecation for /dev/umad users is that they all receive locally
unique TID prefixes. The kernel may be OK to keep things port-specific
> On 27 Apr 2018, at 21:08, Doug Ledford wrote:
>
> On Thu, 2018-04-26 at 20:51 +0200, Håkon Bugge wrote:
>>> Jason is out this week. I'll end up processing this one (probably later
>>> today). But I’ll fix up the commit message to suit my tastes when I do.
>>
>> Thank
> On 27 Apr 2018, at 21:08, Doug Ledford wrote:
>
> On Thu, 2018-04-26 at 20:51 +0200, Håkon Bugge wrote:
>>> Jason is out this week. I'll end up processing this one (probably later
>>> today). But I’ll fix up the commit message to suit my tastes when I do.
>>
>> Thank you, Doug and Jack,
>
On Thu, 2018-04-26 at 20:51 +0200, Håkon Bugge wrote:
> > Jason is out this week. I'll end up processing this one (probably later
> > today). But I’ll fix up the commit message to suit my tastes when I do.
>
> Thank you, Doug and Jack,
I reworded the commit message, let me know if you think I
On Thu, 2018-04-26 at 20:51 +0200, Håkon Bugge wrote:
> > Jason is out this week. I'll end up processing this one (probably later
> > today). But I’ll fix up the commit message to suit my tastes when I do.
>
> Thank you, Doug and Jack,
I reworded the commit message, let me know if you think I
On Thu, 26 Apr 2018 18:06:10 +0200
Håkon Bugge wrote:
> > On 23 Apr 2018, at 21:16, jackm wrote:
> >
> > On Mon, 23 Apr 2018 16:19:57 +0200
> > Håkon Bugge wrote:
> >
> >
> >>>
> >>> This actually looks like a
On Thu, 26 Apr 2018 18:06:10 +0200
Håkon Bugge wrote:
> > On 23 Apr 2018, at 21:16, jackm wrote:
> >
> > On Mon, 23 Apr 2018 16:19:57 +0200
> > Håkon Bugge wrote:
> >
> >
> >>>
> >>> This actually looks like a genuine bug, why is it described only
> >>> as 'confusing'?
> On 23 Apr 2018, at 21:16, jackm wrote:
>
> On Mon, 23 Apr 2018 16:19:57 +0200
> Håkon Bugge wrote:
>
>
>>>
>>> This actually looks like a genuine bug, why is it described only as
>>> 'confusing'? ib_register_mad_agent is callable from
> On 23 Apr 2018, at 21:16, jackm wrote:
>
> On Mon, 23 Apr 2018 16:19:57 +0200
> Håkon Bugge wrote:
>
>
>>>
>>> This actually looks like a genuine bug, why is it described only as
>>> 'confusing'? ib_register_mad_agent is callable from userspace, so at
>>> least two userspace agents can
On Mon, 23 Apr 2018 16:19:57 +0200
Håkon Bugge wrote:
> >
> > This actually looks like a genuine bug, why is it described only as
> > 'confusing'? ib_register_mad_agent is callable from userspace, so at
> > least two userspace agents can race and get the same TID’s.
On Mon, 23 Apr 2018 16:19:57 +0200
Håkon Bugge wrote:
> >
> > This actually looks like a genuine bug, why is it described only as
> > 'confusing'? ib_register_mad_agent is callable from userspace, so at
> > least two userspace agents can race and get the same TID’s.
>
> My understanding is
+Jack
> On 20 Apr 2018, at 17:34, Jason Gunthorpe wrote:
>
> On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote:
>> On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote:
>>> Two kernel threads may get the same value for agent.hi_tid, if the
>>> agents are registered
+Jack
> On 20 Apr 2018, at 17:34, Jason Gunthorpe wrote:
>
> On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote:
>> On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote:
>>> Two kernel threads may get the same value for agent.hi_tid, if the
>>> agents are registered for different
On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote:
> On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote:
> > Two kernel threads may get the same value for agent.hi_tid, if the
> > agents are registered for different ports. As of now, this works, as
> > the agent list is per port.
> >
On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote:
> On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote:
> > Two kernel threads may get the same value for agent.hi_tid, if the
> > agents are registered for different ports. As of now, this works, as
> > the agent list is per port.
> >
On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote:
> Two kernel threads may get the same value for agent.hi_tid, if the
> agents are registered for different ports. As of now, this works, as
> the agent list is per port.
>
> It is however confusing and not future robust. Hence, making it
>
On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote:
> Two kernel threads may get the same value for agent.hi_tid, if the
> agents are registered for different ports. As of now, this works, as
> the agent list is per port.
>
> It is however confusing and not future robust. Hence, making it
>
On 2018/4/18 22:24, Håkon Bugge wrote:
Two kernel threads may get the same value for agent.hi_tid, if the
agents are registered for different ports. As of now, this works, as
the agent list is per port.
It is however confusing and not future robust. Hence, making it
atomic.
Signed-off-by:
On 2018/4/18 22:24, Håkon Bugge wrote:
Two kernel threads may get the same value for agent.hi_tid, if the
agents are registered for different ports. As of now, this works, as
the agent list is per port.
It is however confusing and not future robust. Hence, making it
atomic.
Signed-off-by:
>
> Two kernel threads may get the same value for agent.hi_tid, if the agents are
> registered for different ports. As of now, this works, as the agent list is
> per port.
>
> It is however confusing and not future robust. Hence, making it atomic.
>
> Signed-off-by: Håkon Bugge
>
> Two kernel threads may get the same value for agent.hi_tid, if the agents are
> registered for different ports. As of now, this works, as the agent list is
> per port.
>
> It is however confusing and not future robust. Hence, making it atomic.
>
> Signed-off-by: Håkon Bugge
> Reviewed-by:
Two kernel threads may get the same value for agent.hi_tid, if the
agents are registered for different ports. As of now, this works, as
the agent list is per port.
It is however confusing and not future robust. Hence, making it
atomic.
Signed-off-by: Håkon Bugge
Two kernel threads may get the same value for agent.hi_tid, if the
agents are registered for different ports. As of now, this works, as
the agent list is per port.
It is however confusing and not future robust. Hence, making it
atomic.
Signed-off-by: Håkon Bugge
Reviewed-by: Jack Morgenstein
34 matches
Mail list logo