On Thu, Apr 30, 2015 at 07:21:08PM +, Hefty, Sean wrote:
> > But, how could RDMA CM work? Inbound CM messages will be filtered if
> > the IP is not in the HW GID table?
>
> I'm not understanding the issue.
>
> If a device has some requirement to program its assigned IP
> addresses into some H
On 4/28/2015 8:43 PM, Jason Gunthorpe wrote:
On Tue, Apr 28, 2015 at 05:03:11PM +0300, Matan Barak wrote:
The cleanup of roce_gid_cache is done in a different context, so we
need to make sure the device is still alive while doing so.
This explanation doesn't look right to me. I don't see an
On Tue, Apr 28, 2015 at 8:43 PM, Jason Gunthorpe
wrote:
> On Tue, Apr 28, 2015 at 05:03:11PM +0300, Matan Barak wrote:
[...]
> Or: This should have been fixed after Haggai brought it up...
Jason, looking again on the correspondence between Matan and Haggai, I
think this one was sort of left in t
On Tue, Apr 28, 2015 at 05:03:11PM +0300, Matan Barak wrote:
> The cleanup of roce_gid_cache is done in a different context, so we
> need to make sure the device is still alive while doing so.
This explanation doesn't look right to me. I don't see anything like
that under roce_gid_cache_cleanup
On 4/28/2015 7:03 PM, Jason Gunthorpe wrote:
On Tue, Apr 28, 2015 at 11:32:08AM +0300, Matan Barak wrote:
This was already asked by Haggai Eran awhile ago and was answered.
Anyway, in ib_unregister_device we delete all client's related data.
We would like to ensure that all references were re
On Tue, Apr 28, 2015 at 11:32:08AM +0300, Matan Barak wrote:
> This was already asked by Haggai Eran awhile ago and was answered.
> Anyway, in ib_unregister_device we delete all client's related data.
> We would like to ensure that all references were released before this
> data is being deleted.
On 4/28/2015 2:51 PM, Or Gerlitz wrote:
On Mon, Apr 27, 2015 at 11:25 AM, Matan Barak wrote:
On 4/26/2015 11:10 PM, Or Gerlitz wrote:
On Thu, Mar 26, 2015 at 12:19 AM, Somnath Kotur
wrote:
From: Matan Barak
Previously. we used device_mutex lock in order to protect
the device's list. Tha
On Mon, Apr 27, 2015 at 11:25 AM, Matan Barak wrote:
> On 4/26/2015 11:10 PM, Or Gerlitz wrote:
>> On Thu, Mar 26, 2015 at 12:19 AM, Somnath Kotur
>> wrote:
>>>
>>> From: Matan Barak
>>>
>>> Previously. we used device_mutex lock in order to protect
>>> the device's list. That means that in order
On 4/27/2015 7:22 PM, Jason Gunthorpe wrote:
On Mon, Apr 27, 2015 at 11:25:56AM +0300, Matan Barak wrote:
On 4/26/2015 11:10 PM, Or Gerlitz wrote:
On Thu, Mar 26, 2015 at 12:19 AM, Somnath Kotur
wrote:
From: Matan Barak
Previously. we used device_mutex lock in order to protect
the devic
On Mon, Apr 27, 2015 at 11:25:56AM +0300, Matan Barak wrote:
>
>
> On 4/26/2015 11:10 PM, Or Gerlitz wrote:
> >On Thu, Mar 26, 2015 at 12:19 AM, Somnath Kotur
> > wrote:
> >>From: Matan Barak
> >>
> >>Previously. we used device_mutex lock in order to protect
> >>the device's list. That means tha
On 4/26/2015 11:10 PM, Or Gerlitz wrote:
On Thu, Mar 26, 2015 at 12:19 AM, Somnath Kotur
wrote:
From: Matan Barak
Previously. we used device_mutex lock in order to protect
the device's list. That means that in order to guarantee a
device isn't freed while we use it, we had to lock all
devic
On Thu, Mar 26, 2015 at 12:19 AM, Somnath Kotur
wrote:
> From: Matan Barak
>
> Previously. we used device_mutex lock in order to protect
> the device's list. That means that in order to guarantee a
> device isn't freed while we use it, we had to lock all
> devices.
Matan, looking on the cover le
On 3/26/2015 1:46 AM, Bart Van Assche wrote:
On 03/25/2015 02:19 PM, Somnath Kotur wrote:
+static void ib_device_complete_cb(struct kref *kref)
+{
+struct ib_device *device = container_of(kref, struct ib_device,
+refcount);
+
+if (device->reg_state >= IB_DEV_UNR
On 03/25/2015 02:19 PM, Somnath Kotur wrote:
+static void ib_device_complete_cb(struct kref *kref)
+{
+ struct ib_device *device = container_of(kref, struct ib_device,
+ refcount);
+
+ if (device->reg_state >= IB_DEV_UNREGISTERING)
+
From: Matan Barak
Previously. we used device_mutex lock in order to protect
the device's list. That means that in order to guarantee a
device isn't freed while we use it, we had to lock all
devices.
Adding a kref per IB device. Before an IB device
is unregistered, we wait before its not held any
15 matches
Mail list logo
