Re: HFI1 code duplication todo

At the beginning when hfi1 was put into staging, then it was easy enough for Greg to take those patches but now it feels awkward. Probably Doug and the linux-rdma@vger.kernel.org people should start maintaining the drivers/staging/rdma directory. Like merge Greg's tree and pull in whatever

RE: [PATCH 02/18] staging/rdma/hfi1: Decode CNP opcode

> > Add CNP opcode decode > > Why? Prior to this patch the trace appeared like: -0 [001] d.h. 94062.578932: input_ibhdr: [:05:00.0] vl 0 lver 0 sl 0 lnh 2,LRH_BTH dlid 0003 len 6 slid 0001 op 0x80,0x80 se 0 m 0 pad 0 tver 0 pkey 0x8001 f 0 b 0 qpn 0x001234 a 0 psn 0x Note the

RE: [PATCH 09/18] staging/rdma/hfi1: Correctly limit VLs against SDMA engines

> > From: Dean Luick > > > > Correctly reduce the number of VLs when limited by the number of SDMA > > engines. > > why? What does this "solve"? The hardware has multiple egress mechanisms, SDMA and pio, and multiples of those. These mechanisms are chosen using the VL

RE: [PATCH v3] staging/rdma/hfi1: set Gen3 half-swing for integrated devices

> > + dd_dev_info(dd, "%s: program XMT margin, CcePcieCtrl 0x%llx\n", > > + fname, pcie_ctrl); > > Why spam the log with this all the time? Shouldn't this be a debug line > instead? The current implementation is layered on dev_info(). Are you saying dev_dbg() is a better

RE: [PATCH 05/18] staging/rdma/hfi1: Clean up comments

> > Clean up comments > > In what way? > The patch deleted numbering and terms internal to intel. The information on the actual bugs is not deleted. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

On Wed, Nov 18, 2015 at 10:20:14AM -0800, Bart Van Assche wrote: > Are you perhaps referring to the sysfs CPU mask that allows to control > workqueue affinity ? I think he is referring to the defintion of WQ_UNBOUND: WQ_UNBOUND Work items queued to an unbound wq are served by the

Re: [PATCH 4/9] srpt: chain RDMA READ/WRITE requests

On Wed, Nov 18, 2015 at 08:32:59AM -0800, Bart Van Assche wrote: > As you know events like a cable pull can cause some of the RDMA work > requests to succeed and others to fail. It is essential that all RDMA work > requests related to the same SCSI command have finished before the buffers >

Re: [PATCH] IB/srp: Fix a memory leak

Looks good, Reviewed-by: Christoph Hellwig -- 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: HFI1 code duplication todo

On 11/20/2015 11:39 AM, Greg KH wrote: > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: >> To that end, I've opened my 4.4-rc branch and deleted the three >> deprecated drivers from staging and moved hfi1 to the rdma tree. I've >> sent an email to Linus to see if he's ok taking

RE: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

> > drivers/staging/rdma/hfi1/sdma.c | 12 ++-- > > 1 files changed, 10 insertions(+), 2 deletions(-) > > Doesn't apply to my tree :( Ok. Is the inprocess branch available? Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to

RE: [PATCH 18/18] staging/rdma/hfi1: Workaround CONFIG_SDMA_VERBOSITY timing issue

> That sounds like a horrid hack, and this implies that a slower machine will > still have this problem... Greg, I'm NAK'ing this patch for two reasons: 1. Code underneath the CONFIG option is only used during rework 2. It is a hack as you have noted We are going to take this up internally to

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

On 11/20/2015 02:16 AM, Christoph Hellwig wrote: > On Wed, Nov 18, 2015 at 10:20:14AM -0800, Bart Van Assche wrote: >> Are you perhaps referring to the sysfs CPU mask that allows to control >> workqueue affinity ? > > I think he is referring to the defintion of WQ_UNBOUND: > >WQ_UNBOUND > >

RE: HFI1 code duplication todo

> > To that end, I've opened my 4.4-rc branch and deleted the three deprecated > drivers from staging and moved hfi1 to the rdma tree. I've sent an email to > Linus to see if he's ok taking those changes, and if so, I'll get them > submitted > and then open up my for-4.5 branch early to be able

Re: HFI1 code duplication todo

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > On 11/19/2015 05:23 PM, Dennis Dalessandro wrote: > > On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote: > >> The major todo for the hfi1 driver in staging is getting rid of the > >> verbs code duplication between

RE: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

> > > > Is the inprocess branch available? > > I do not understand what you mean here :( Does it fail to apply to staging-next or staging-testing or something else? Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to

Re: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

On Fri, Nov 20, 2015 at 04:43:56PM +, Marciniszyn, Mike wrote: > > > > > > Is the inprocess branch available? > > > > I do not understand what you mean here :( > > Does it fail to apply to staging-next or staging-testing or something else? As both trees are now the same, it fails to apply

RE: [PATCH 07/18] staging/rdma/hfi1: Extend quiet timeout

> > The longest quiet timeout is now 6s. Extend the driver wait. > > To what? And why? What does this fix? > The driver wasn't following the our internal specification: 6 seconds. The patch corrects that issue. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rdma"

Re: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

On Fri, Nov 20, 2015 at 03:23:55PM +, Marciniszyn, Mike wrote: > > > drivers/staging/rdma/hfi1/sdma.c | 12 ++-- > > > 1 files changed, 10 insertions(+), 2 deletions(-) > > > > Doesn't apply to my tree :( > > Ok. > > Is the inprocess branch available? I do not understand what

[PATCH] IB/iser: use sector_div instead of do_div

do_div is the wrong way to divide a sector_t, as it is less efficient when sector_t is 32-bit wide. With the upcoming do_div optimizations, the kernel starts warning about this: drivers/infiniband/ulp/iser/iser_verbs.c:1296:4: note: in expansion of macro 'do_div'

Re: HFI1 code duplication todo

On 11/19/2015 05:23 PM, Dennis Dalessandro wrote: > On Thu, Nov 12, 2015 at 04:13:18PM -0500, Dennis Dalessandro wrote: >> The major todo for the hfi1 driver in staging is getting rid of the >> verbs code duplication between ipath, qib, and now hfi1. The ipath >> driver has been deprecated and is

Re: [PATCH v3] staging/rdma/hfi1: set Gen3 half-swing for integrated devices

On Fri, Nov 20, 2015 at 03:14:19PM +, Marciniszyn, Mike wrote: > > > + dd_dev_info(dd, "%s: program XMT margin, CcePcieCtrl 0x%llx\n", > > > + fname, pcie_ctrl); > > > > Why spam the log with this all the time? Shouldn't this be a debug line > > instead? > > The current

Re: HFI1 code duplication todo

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > To that end, I've opened my 4.4-rc branch and deleted the three > deprecated drivers from staging and moved hfi1 to the rdma tree. I've > sent an email to Linus to see if he's ok taking those changes, and if > so, I'll get them

RE: [PATCH v3] staging/rdma/hfi1: set Gen3 half-swing for integrated devices

> > Are you saying dev_dbg() is a better choice? > > Yes, why would a user ever want to see that above line? What can they do > with it? Will do. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH 18/18] staging/rdma/hfi1: Workaround CONFIG_SDMA_VERBOSITY timing issue

On Fri, Nov 20, 2015 at 04:01:18PM +, Marciniszyn, Mike wrote: > > That sounds like a horrid hack, and this implies that a slower machine will > > still have this problem... > > Greg, > > I'm NAK'ing this patch for two reasons: > 1. Code underneath the CONFIG option is only used during

Re: HFI1 code duplication todo

On Fri, Nov 20, 2015 at 11:58:18AM -0500, Doug Ledford wrote: > On 11/20/2015 11:39 AM, Greg KH wrote: > > On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > >> To that end, I've opened my 4.4-rc branch and deleted the three > >> deprecated drivers from staging and moved hfi1 to the

Re: HFI1 code duplication todo

On 11/20/2015 12:13 PM, Greg KH wrote: >>> I think it's too late for that, especially given that I have 34+ patches >>> for the staging rdma drivers already in my tree in linux-next. >> >> For hfi1 rename detection should work, for the other three, patches to >> removed files are easily resolved

[PATCH] IB/cma: Add a missing rcu_read_unlock()

Ensure that validate_ipv4_net_dev() calls rcu_read_unlock() if fib_lookup() fails. Detected by sparse. Compile-tested only. Fixes: "IB/cma: Validate routing of incoming requests" (commit f887f2ac87c2). Cc: Haggai Eran Cc: stable ---

Re: [PATCH 07/18] staging/rdma/hfi1: Extend quiet timeout

On Fri, Nov 20, 2015 at 03:21:14PM +, Marciniszyn, Mike wrote: > > > The longest quiet timeout is now 6s. Extend the driver wait. > > > > To what? And why? What does this fix? > > > > The driver wasn't following the our internal specification: 6 seconds. > > The patch corrects that

RE: [PATCH 03/18] staging/rdma/hfi1: Add aeth name syndrome decode

> > Add aeth name syndrome decode > > Again, why? > This fix is to enhance debugging. The IBTA RC ACK contains an ACK extended transport header. Part of that header is the syndrome field that qualifies the RC ACK as an ACK, NAK, or RNR NAK. Without the patch here is the syndrome decode:

[PATCH v3] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

From: Ira Weiny sdma_select_engine_vl only needs to protect itself from an invalid VL. Something higher up the stack should be warning the user when they try to use an SL which maps to an invalid VL. Reviewed-by: Dean Luick Reviewed-by: Mike Marciniszyn

Re: HFI1 code duplication todo

On Fri, Nov 20, 2015 at 10:41:16AM -0500, Doug Ledford wrote: > So, as to the hfi1/qib/rxe transport library. The qib driver is in the > rdma tree, and we aren't going to move it to staging just because it > depends on something in staging, so we need to start adding the library > in the core

[PATCH] staging/rdma/hfi1: Fix error in hfi1 driver build

hfi1 driver build fails with the following error: In function ‘handle_receive_interrupt’: error: implicit declaration of function ‘skip_rcv_packet’ [-Werror=implicit-function-declaration] last = skip_rcv_packet(, thread); ^ This is due to the inclusion of the skip_rcv_packet() in the

Re: [PATCH v2 2/2] staging/rdma/hfi1: Eliminate WARN_ON when VL is invalid

On Fri, Nov 20, 2015 at 09:00:23AM -0800, Greg KH wrote: > On Fri, Nov 20, 2015 at 04:43:56PM +, Marciniszyn, Mike wrote: > > > > > > > > Is the inprocess branch available? > > > > > > I do not understand what you mean here :( > > > > Does it fail to apply to staging-next or staging-testing

Re: [PATCH 5/9] staging/rdma/hfi1: Add function stubs for TID caching

On Fri, Nov 20, 2015 at 3:06 AM, Greg Kroah-Hartman wrote: > On Thu, Nov 12, 2015 at 07:58:54AM +0200, Or Gerlitz wrote: >> On Sat, Oct 31, 2015 at 12:41 AM, wrote: >> So this is an wholy orthogonal mechanism for memory registrations or >>

Re: [PATCH] IB/cma: Add a missing rcu_read_unlock()

Ensure that validate_ipv4_net_dev() calls rcu_read_unlock() if fib_lookup() fails. Detected by sparse. Compile-tested only. Fixes: "IB/cma: Validate routing of incoming requests" (commit f887f2ac87c2). Cc: Haggai Eran Cc: stable Looks good,

Re: [PATCH] IB/iser: use sector_div instead of do_div

do_div is the wrong way to divide a sector_t, as it is less efficient when sector_t is 32-bit wide. With the upcoming do_div optimizations, the kernel starts warning about this: drivers/infiniband/ulp/iser/iser_verbs.c:1296:4: note: in expansion of macro 'do_div'

Re: [PATCH] IB/srp: Fix a memory leak

On 19/11/2015 01:00, Bart Van Assche wrote: If srp_connect_ch() returns a positive value then that is considered by its caller as a connection failure but this does not result in a scsi_host_put() call and additionally causes the srp_create_target() function to return a positive value while it