Re: [PATCH 1/3] IB Core: Create get_perf_mad function in sysfs.c

On Thu, Dec 31, 2015 at 08:58:31AM +0100, Bart Van Assche wrote: > On 12/17/2015 08:52 PM, Christoph Lameter wrote: > >-in_mad->mad_hdr.attr_id = cpu_to_be16(0x12); /* PortCounters */ > >+in_mad->mad_hdr.attr_id = attr; > > Hello Christoph, > > sparse reports an endianness

Re: [PATCH] IB/mad: Ensure fairness in ib_mad_completion_handler

On Sat, Jan 02, 2016 at 09:03:31AM -0800, Christoph Hellwig wrote: > On Wed, Dec 30, 2015 at 09:00:07PM -0500, ira.weiny wrote: > > On Wed, Dec 30, 2015 at 03:01:33AM -0800, Christoph Hellwig wrote: > > > Hi Ira, > > > > > > please take a look at the patches I've attached - they are just WIP > >

[PATCH] IB/sysfs: Fix sparse warning on attr_id

From: Ira Weiny Attributed ID was declared as an int while the value should really be big endian 16. Fixes: 35c4cbb17811 ("IB/core: Create get_perf_mad function in sysfs.c") Reported-by: Bart Van Assche Signed-off-by: Ira Weiny

Re: [PATCH] IB/mad: Ensure fairness in ib_mad_completion_handler

On Wed, Dec 30, 2015 at 03:01:33AM -0800, Christoph Hellwig wrote: > Hi Ira, > > please take a look at the patches I've attached - they are just WIP > that hasn't been tested as I'm on a vacation without access to my > IB setup until New Year's Eve. > > Patch 1 is I think a genuine bug fix

Re: [PATCH v2 00/10] iSER support for remote invalidate

On Wed, Dec 23, 2015 at 10:53 PM, Or Gerlitz wrote: > On Mon, Dec 21, 2015 at 3:29 PM, Sagi Grimberg > wrote: > >>> Sagi, are you going to spin an increment in the initiator version? > >> I don't know if it's worth a driver version update? > >

Re: [PATCH] IB/sysfs: Fix sparse warning on attr_id

On Mon, Jan 4, 2016 at 5:44 AM, wrote: > From: Ira Weiny > > Attributed ID was declared as an int while the value should really be big > endian 16. > > Fixes: 35c4cbb17811 ("IB/core: Create get_perf_mad function in sysfs.c") > remove this blank line

Re: [PATCH] IB/mad: Ensure fairness in ib_mad_completion_handler

On Wed, Dec 30, 2015 at 03:01:33AM -0800, Christoph Hellwig wrote: > Hi Ira, > > please take a look at the patches I've attached - they are just WIP > that hasn't been tested as I'm on a vacation without access to my > IB setup until New Year's Eve. > > Patch 1 is I think a genuine bug fix

Re: [PATCH 3/3] IB/srpt: Fix a race condition related to SRP login

On Thu, Dec 31, 2015 at 09:57:58AM +0100, Bart Van Assche wrote: > Since patch "IB/srpt: chain RDMA READ/WRITE requests" there are > two loops that process the command wait list. ch->cmd_wait_list > is accessed without locking which means that all code that > accesses this list must be serialized.

Re: [PATCH 2/3] IB/srpt: Fix the RDMA completion handlers

Looks good, Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] irq_poll: Fix irq_poll_sched()

Looks good, Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] IB/srpt: Fix a race condition related to SRP login

But now the first I/O(s) could be lost if no other I/O comes in, right? I suspect that we need to keep this loop to protect against such corner cases. It can happen theoretically, but why do we even bother? Why not just post the recv buffer after we moved in to CH_LIVE? This why we let the

Re: [PATCH 3/3] IB/srpt: Fix a race condition related to SRP login

On 01/03/2016 12:25 PM, Sagi Grimberg wrote: But now the first I/O(s) could be lost if no other I/O comes in, right? I suspect that we need to keep this loop to protect against such corner cases. It can happen theoretically, but why do we even bother? Why not just post the recv buffer after

Re: [PATCH 3/3] IB/srpt: Fix a race condition related to SRP login

But now the first I/O(s) could be lost if no other I/O comes in, right? I suspect that we need to keep this loop to protect against such corner cases. It can happen theoretically, but why do we even bother? Why not just post the recv buffer after we moved in to CH_LIVE? This why we let the

[PATCH for-next 1/2] IB/core: Rename rdma_addr_find_dmac_by_grh

rdma_addr_find_dmac_by_grh resolves dmac, vlan_id and if_index and downsteram patch will also add hop_limit as an output parameter, thus we rename it to rdma_addr_find_l2_eth_by_grh. Signed-off-by: Matan Barak --- drivers/infiniband/core/addr.c | 7 ---

[PATCH for-next 2/2] IB/core: Use hop-limit from IP stack for RoCE

Previously, IPV6_DEFAULT_HOPLIMIT was used as the hop limit value for RoCE. Fixing that by taking ip4_dst_hoplimit and ip6_dst_hoplimit as hop limit values. Signed-off-by: Matan Barak --- drivers/infiniband/core/addr.c | 9 - drivers/infiniband/core/cm.c

[PATCH for-next 0/2] Fix hop-limit for RoCE

Hi Doug, Previously, the hop limit of RoCE packets were set to IPV6_DEFAULT_HOPLIMIT. This generally works, but RoCE stack needs to follow the IP stack rules. Therefore, this patch series use ip4_dst_hoplimit and ip6_dst_hoplimit in order to set the correct hop limit for RoCE traffic. The first

Re: [PATCH for-next 2/2] IB/core: Use hop-limit from IP stack for RoCE

On Sun, Jan 03, 2016 at 03:59:11PM +0200, Matan Barak wrote: > @@ -434,6 +434,7 @@ int ib_init_ah_from_wc(struct ib_device *device, u8 > port_num, > int ret; > enum rdma_network_type net_type = RDMA_NETWORK_IB; > enum ib_gid_type gid_type = IB_GID_TYPE_IB; > + int hoplimit =