Re: [PATCH net-next 0/2] new maintainers for Mellanox mlx4/mlx5 core and IB drivers
From: Doug Ledford Date: Wed, 23 Dec 2015 13:31:06 -0500 > On 12/23/2015 11:30 AM, Or Gerlitz wrote: >> Hi Dave, Doug >> >> We're happily assigning new maintainers for mlx4/mlx5 core and IB drivers. >> >> This is aligned with Eli (mlx5) and Roland (mlx4). >> >> FWIW, I did the whole change to go through netdev. > > Hi Dave, I've picked these up. Ok, thanks! -- 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 for-next 0/2] RDMA/cxgb4: Add iWARP support for T6 adapter
From: Doug Ledford Date: Wed, 21 Oct 2015 16:58:50 -0400 > Probably. Unless David objects, I'll queue them up. No objection from me. -- 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 v2 05/14] RDS: defer the over_batch work to send worker
From: Santosh Shilimkar
Date: Wed, 30 Sep 2015 13:24:24 -0400
> @@ -423,7 +423,9 @@ over_batch:
>!list_empty(&conn->c_send_queue)) &&
> send_gen == conn->c_send_gen) {
> rds_stats_inc(s_send_lock_queue_raced);
> - goto restart;
> + if (batch_count < 1024)
> + goto restart;
> + queue_delayed_work(rds_wq, &conn->c_send_w, 1);
Sorry, you can't just use a magic number like this.
You have to describe, in detail, exactly how this value was
choosen, derived, and tested to be effeective and in exactly
what environment those tests were done.
You must also use a mnenomic for this value rather than a
raw magic constant.
Thanks.
--
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: message size, was Re: merge struct ib_device_attr into struct ib_device
From: "Steve Wise" Date: Tue, 22 Sep 2015 17:15:15 -0500 > How do we change the message size limits? Reviewing w/o it being > inline is painful for the (many) reviewers... I've increased it. -- 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 -next] net/mlx5_core: fix an error code
From: Dan Carpenter
Date: Thu, 11 Jun 2015 11:50:01 +0300
> We return success if mlx5e_alloc_sq_db() fails but we should return an
> error code.
>
> Fixes: f62b8bb8f2d3 ('net/mlx5: Extend mlx5_core to support ConnectX-4
> Ethernet functionality')
> Signed-off-by: Dan Carpenter
Applied, thanks Dan.
--
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 net] net/mlx4_core: Fix reading HCA max message size in mlx4_QUERY_DEV_CAP
From: Or Gerlitz
Date: Tue, 21 Apr 2015 15:46:34 +0300
> From: Eran Ben Elisha
>
> Currently we parse max_msg_sz from the wrong offset in QUERY_DEV_CAP,
> fix to use the right offset.
>
> Fixes: 0b131561a7d6 ('net/mlx4_en: Add Flow control statistics [..]')
> Signed-off-by: Eran Ben Elisha
> Signed-off-by: Or Gerlitz
Applied, thanks.
--
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 V1 net-next] IB/ipoib: Fix ndo_get_iflink
From: Haggai Eran
Date: Mon, 20 Apr 2015 11:16:34 +0300
> On 17/04/2015 22:21, David Miller wrote:
>> From: Erez Shitrit
>> Date: Thu, 16 Apr 2015 16:34:34 +0300
>>
>>> Currently, iflink of the parent interface was always accessed, even
>>> when interface didn't have a parent and hence we crashed there.
>>>
>>> Handle the interface types properly: for a child interface, return
>>> the ifindex of the parent, for parent interface, return its ifindex.
>>>
>>> For child devices, make sure to set the parent pointer prior to
>>> invoking register_netdevice(), this allows the new ndo to be called
>>> by the stack immediately after the child device is registered.
>>>
>>> Fixes: 5aa7add8f14b ('infiniband/ipoib: implement ndo_get_iflink')
>>> Reported-by: Honggang Li
>>> Signed-off-by: Erez Shitrit
>>> Signed-off-by: Honggang Li
>>
>> Applied, thanks.
>
> Doug, Roland,
>
> You might want to include this patch in your for-next / for-4.1 trees,
> or merge net-next again. Currently they contain the issue it fixes, and
> it can prevent some systems with IPoIB from booting.
I put this into 'net', not 'net-next'. 'net-next' is dormant after I do
my first push to Linus of the merge window. After that everything goes
via 'net' until the merge window closes and I open 'net-next' up again.
--
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 V1 net-next] IB/ipoib: Fix ndo_get_iflink
From: Erez Shitrit
Date: Thu, 16 Apr 2015 16:34:34 +0300
> Currently, iflink of the parent interface was always accessed, even
> when interface didn't have a parent and hence we crashed there.
>
> Handle the interface types properly: for a child interface, return
> the ifindex of the parent, for parent interface, return its ifindex.
>
> For child devices, make sure to set the parent pointer prior to
> invoking register_netdevice(), this allows the new ndo to be called
> by the stack immediately after the child device is registered.
>
> Fixes: 5aa7add8f14b ('infiniband/ipoib: implement ndo_get_iflink')
> Reported-by: Honggang Li
> Signed-off-by: Erez Shitrit
> Signed-off-by: Honggang Li
Applied, thanks.
--
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 linux-next v2] mlx5: wrong page mask if CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for 32Bit architectures
From: Honggang Li Date: Mon, 13 Apr 2015 17:21:58 +0800 > If CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for x86 systems and physical > memory is more than 4GB, dma_map_page may return a valid memory > address which greater than 0x. As a result, the mlx5 device page > allocator RB tree will be initialized with valid addresses greater than > 0xfff. > > However, (addr & PAGE_MASK) set the high four bytes to zeros. So, it's > impossible for the function, free_4k, to release the pages whose > addresses greater than 4GB. Memory leaks. And mlx5_ib module can't > release the pages when user try to remove the module, as a result, > system hang. > > [root@rdma05 root]# dmesg | grep addr | head > addr = 3fe384000 > addr & PAGE_MASK = fe384000 > [root@rdma05 root]# rmmod mlx5_ib < hang on > > -- cosnole log - > mlx5_ib :04:00.0: irq 138 for MSI/MSI-X > alloc irq_desc for 139 on node -1 > alloc kstat_irqs on node -1 > mlx5_ib :04:00.0: irq 139 for MSI/MSI-X > :04:00.0:free_4k:221:(pid 1519): page not found > :04:00.0:free_4k:221:(pid 1519): page not found > :04:00.0:free_4k:221:(pid 1519): page not found > :04:00.0:free_4k:221:(pid 1519): page not found > -- cosnole log - > > Signed-off-by: Honggang Li Please someone at Mellanox review this. -- 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 linux-next 3/4] macvlan: fix possible NULL pointer dereference in macvlan_dev_get_iflink
From: Honggang LI Date: Tue, 14 Apr 2015 23:32:39 +0800 > On Tue, Apr 14, 2015 at 04:26:27PM +0100, Patrick McHardy wrote: >> >> That is completely useless. vlan (=netdev_priv) can not be NULL as >> netdev_priv() never returns NULL and vlan->lowerdev is always valid >> because a macvlan wouldn't make much sense otherwise. > > OK, please drop this patch. That's not how this works. When a patch series needs any chnages, you must make a fresh, new complete submission of the entire patch series. -- 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 net-next v2 3/4] cxgb4: add DDP support for FCoE target
From: Varun Prakash
Date: Mon, 13 Apr 2015 19:34:25 +0530
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_fcoe.c
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_fcoe.c
> index 6c8a62e..f78d632 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_fcoe.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_fcoe.c
...
> + */
> +static inline unsigned int pages2ppods(unsigned int pages)
> +{
> + return (pages + PPOD_PAGES - 1) / PPOD_PAGES +
Please do not ever use inline in foo.c file function definitions. Let
the compiler decide on it's own.
Thanks.
--
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 for-next 0/9] mlx4 changes in virtual GID management
From: Roland Dreier Date: Sun, 5 Apr 2015 07:51:08 -0700 > On Sat, Apr 4, 2015 at 10:15 PM, Or Gerlitz wrote: >> Indeed. No maintainer voice makes it kind of impossible for >> discussions to converge. What happens over the last years is that when >> there's no easy consensus on matter Y, everyone stops breathing and >> wait to see what happens on the rc1 night, b/c Roland doesn't spell >> his view/preference (nor exposes his for-next branch till the last >> minute, see now) many times it seems more as coin flipping. > > To me this attitude shows a failure of the community. If I need to > make every decision, then that doesn't scale. People can ask > questions a lot more easily than I can answer them. No, you need to step in and be the benevolent dictator when people have their thumbs up their asses and can't make up their minds, otherwise things grind to a halt. -- 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 for-next 0/9] mlx4 changes in virtual GID management
From: Christoph Lameter Date: Tue, 31 Mar 2015 07:49:38 -0500 (CDT) > Well this needs to be addressed yes but in order to have that done someone > needs to step forward do the proper work, maintain git trees, do the > review and show up for the conferences. Neither Roland nor Or was there at > the Infiniband conferences in Monterey this year(!) and this is the prime > venue for face to face conversation about the subsystem each year. I don't go to IETF meetings, ever, yet I am rather sure that nobody uses that to question my ability to be the networking maintainer. I've gone several years at times without meeting other networking developers as well, and that also I am pretty sure did not harm my stature as the networking maintainer. So I absolutely disagree that these two acts are requirements for someone whose job is to steadily and reasonably review and apply patches for a subsystem. -- 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 for-next 0/9] mlx4 changes in virtual GID management
From: Or Gerlitz Date: Tue, 31 Mar 2015 14:22:50 +0300 > On Tue, Mar 31, 2015 at 6:47 AM, Roland Dreier wrote: >>> Roland, I have to genuinely agree with Or, that your handling of >>> patch integration is sub-par and really painful for anyone actually >>> trying to get real work done here. >>> >>> If you simply don't have the time to devote to constantly reviewing >>> patches as they come in, and doing so in a timely manner, please let >>> someone who is actually interested and has the time to take over. >> >> It's a fair criticism, and certainly for at least the last year or so >> I have not had the time to do enough work as a maintainer. I have >> hope that some of the things that have been keeping me busy are dying >> down and that I'll have more time to spend on handling the RDMA tree, >> but that's just talk until I actually get more done. > > Roland, well, with few variations, this goes way beyond a year. I > would say more or less half of the time you're wearing the maintainer > hat (2005-now). The practice of updating your for-next branch to rc1 > only few days/hours before the the kernel is out and the merge window > opens, is an attitude, not lack of resources and will not be solved by > whatever processes people suggest. You need to act differently. Unfortunately, and no direct offense intend to you personally Roland, but I agree with Or here. If a person really cares about a subsystem they are marked at the maintainer for, they usually _make_ the time necessary to apply patches and attend to maintainership in a reasonable manner. If this "once every merge window" behavior was limited to one release cycle, I'd give the benefit of the doubt, but this has been going on for a very long time. You cannot on the one hand say "I care about this subsystem and the long term maintainership and ABI stability of it" yet on the other hand not be willing to put forth even the _MOST MINIMAL_ amount of effort and time required to steadily review and apply patches over a period of several years. It doesn't take a lot of time to do this work, especially if you use the correct tools. I can review and apply 100 patches a day, even when I'm on vacation. I'm an extreme example, but what you're doing right now Roland is not acceptable and is not in agreement with your claims about how much you care about this subsystem. If you processed the incoming patch queue even _once_ a week, we wouldn't even be having this conversation. But you haven't even been doing that. I get sick to my stomache when a patch gets to 3 days in my patch queue, that's already too long. -- 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 for-next 0/9] mlx4 changes in virtual GID management
From: Or Gerlitz Date: Mon, 30 Mar 2015 19:17:01 +0300 > On Sun, Mar 29, 2015 at 4:51 PM, Or Gerlitz wrote: >> Under the existing implementation for virtual GIDs, if the SM is not >> reachable or incurs a delayed response, or if the VF is probed into a >> VM before their GUID is registered with the SM, there exists a window >> in time in which the VF sees an incorrect GID, i.e., not the GID that >> was intended by the admin. This results in exposing a temporal identity >> to the VF. > > Hi Roland, so your for-next branch is again way behind, still on 3.19 > and while 4.0 is soon @ rc6, we couldn't even rebase this series on > it. It's really hard where your tree is really active once every nine > weeks or so, e.g only few days before/after rc1's. I'm not sure what > you expect us to do, kernel development simply needs not be like this. > > April 3rd-12th is holiday here, and we would like to really really > know early this week what you intend to pull for 4.1 out of the > pending things in linux-rdma. Roland, I have to genuinely agree with Or, that your handling of patch integration is sub-par and really painful for anyone actually trying to get real work done here. If you simply don't have the time to devote to constantly reviewing patches as they come in, and doing so in a timely manner, please let someone who is actually interested and has the time to take over. Only integrating peoples work right before the merge window, and then disappearing for a long time really isn't acceptable. Thanks! -- 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/15] net/mlx5_core: don't export static symbol
From: Julia Lawall Date: Wed, 11 Mar 2015 17:56:25 +0100 > From: Julia Lawall > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) ... > Signed-off-by: Julia Lawall Applied, thank you Julia. -- 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 v2] net: Mellanox: Delete unnecessary checks before the function call "vunmap"
From: SF Markus Elfring Date: Mon, 09 Feb 2015 11:21:26 +0100 > From: Markus Elfring > Date: Mon, 9 Feb 2015 11:10:41 +0100 > > The vunmap() function performs also input parameter validation. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > Acked-by: Eli Cohen Applied. -- 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] net: Mellanox: Delete unnecessary checks before the function call "vunmap"
From: SF Markus Elfring Date: Wed, 04 Feb 2015 15:22:33 +0100 > From: Markus Elfring > Date: Wed, 4 Feb 2015 15:17:00 +0100 > > The vunmap() function performs also input parameter validation. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring This does not apply cleanly to the net-next tree, please respin. -- 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 for-next 0/2] Refactor macros to conform to uniform standards
From: Hariprasad Shenai Date: Fri, 16 Jan 2015 09:24:46 +0530 > This patch series cleansup macros/register defines, defined in t4.h and > t4fw_ri_api.h and all the affected files. > > This patch series is created against net-next tree and includes patches on > iw_cxgb4 tree. Since the patches are dependent on previous cleanup patched we > would line to get this series merged through net-next tree. > > We have included all the maintainers of respective drivers. Kindly review the > change and let us know in case of any review comments. Series applied, thanks. -- 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] infiniband: mlx5: avoid a compile-time warning
From: Arnd Bergmann Date: Tue, 13 Jan 2015 17:09:43 +0100 > The return type of find_first_bit() is architecture specific, > on ARM it is 'unsigned int', while the asm-generic code used > on x86 and a lot of other architectures returns 'unsigned long'. > > When building the mlx5 driver on ARM, we get a warning about > this: > > infiniband/hw/mlx5/mem.c: In function 'mlx5_ib_cont_pages': > infiniband/hw/mlx5/mem.c:84:143: warning: comparison of distinct pointer > types lacks a cast > m = min(m, find_first_bit(&tmp, sizeof(tmp))); > > This patch changes the driver to use min_t to make it behave > the same way on all architectures. > > Signed-off-by: Arnd Bergmann Applied. -- 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] mlx5: avoid build warnings on 32-bit
From: Arnd Bergmann Date: Tue, 13 Jan 2015 17:08:06 +0100 > The mlx5 driver passes a string pointer in through a 'u64' variable, > which on 32-bit machines causes a build warning: > > drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function > 'qp_read_field': > drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:303:11: warning: cast from > pointer to integer of different size [-Wpointer-to-int-cast] > > The code is in fact safe, so we can shut up the warning by adding > extra type casts. > > Signed-off-by: Arnd Bergmann Applied. -- 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 net-next 0/2] All Chelsio drivers : Cleanup CPL messages macros
From: Anish Bhatt Date: Thu, 8 Jan 2015 21:38:14 -0800 > This patch series cleans up all register defines/MACROS defined in t4_msg.h > and > affected files as part of the continuing cleanup effort > > The patches series is created against 'net-next' tree and includes patches > to the cxgb4, cxgb4vf, iw_cxgb4, cxgb4i and csiostor drivers. > > We have included all the maintainers of respective drivers. Kindly review the > change and let us know in case of any review comments. Looks fine, applied to net-next, thanks. -- 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 net-next 0/5] RDMA/cxgb4/cxgb4vf/csiostor: Cleanup register defines
From: Hariprasad Shenai Date: Mon, 5 Jan 2015 16:30:42 +0530 > This series continues to cleanup all the macros/register defines related to > SGE, PCIE, MC, MA, TCAM, MAC, etc that are defined in t4_regs.h and the > affected files. > > Will post another 1 or 2 series so that we can cover all the macros so that > they all follow the same style to be consistent. > > The patches series is created against 'net-next' tree. > And includes patches on cxgb4, cxgb4vf, iw_cxgb4 and csiostor driver. > > We have included all the maintainers of respective drivers. Kindly review the > change and let us know in case of any review comments. Series applied, thanks. -- 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] bonding: move ipoib_header_ops to vmlinux
From: Wengang Date: Tue, 30 Dec 2014 11:01:42 +0800 > There are more than one way we do things. For this case, considering > needs, complexity and stability I think moving ipoib_header_ops is the > right way to go. I completely disagree, it's a gross hack at best. It's papering over the real problem. When we have references to released objects in other areas of the networking stack, we don't move those objects into the static kernel image as a fix. -- 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] bonding: move ipoib_header_ops to vmlinux
From: Wengang Wang Date: Tue, 30 Dec 2014 11:04:42 +0800 > When last slave of a bonding master is removed, the bonding then does not > work. > At the time if packet_snd is called against with a master net_device, it calls > then header_ops->create which points to slave's header_ops. In case the slave > is ipoib and the module is unloaded, header_ops would point to invalid > address. > Accessing it will cause problem. > This patch tries to fix this issue by moving ipoib_header_ops to vmlinux to > keep > it valid even when ipoib module is unloaded. > > Signed-off-by: Wengang Wang Like others, I absolutely do not consider it sustainable to keep moving header_ops implementations into the static kernel image. We're just papering over the real problem, which is making sure all dangling references to something really go away when we release/unload an object. Point it to a dummy set of ops and do a synchronize_net() or similar. I'm not applying this patch, sorry. -- 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] bonding: move ipoib_header_ops to vmlinux
From: Wengang Date: Mon, 29 Dec 2014 15:11:32 +0800 > So, what information else do you need? I need a patch formally (re-)submitted. -- 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 net-next 0/9] mlx5 driver updates
From: Eli Cohen Date: Tue, 2 Dec 2014 12:26:10 +0200 > The following series contains some fixes to mlx5 as well as update to the list > of supported devices. Series applied, thanks. -- 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] bonding: move ipoib_header_ops to vmlinux
From: Jay Vosburgh Date: Tue, 25 Nov 2014 10:41:17 -0800 > Or Gerlitz wrote: > >>On 11/25/2014 8:07 AM, David Miller wrote: >>> IPOIB should not work over bonding as it requires that the device >>> use ARPHRD_ETHER. >> >>Hi Dave, >> >>IPoIB devices can be enslaved to both bonding and teaming in their HA mode, >>the bond device type becomes ARPHRD_INFINIBAND when this happens. > > The point was that pktgen disallows ARPHRD_INFINIBAND, not that > bonding does. > > Pktgen specifically checks for type != ARPHRD_ETHER, so the > IPoIB bond should not be able to be used with pkgten. My suspicion is > that pktgen is being configured on the bond first, then an IPoIB slave > is added to the bond; this would change its type in a way that pktgen > wouldn't notice. +1 -- 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] bonding: move ipoib_header_ops to vmlinux
From: Wengang Wang Date: Tue, 25 Nov 2014 13:36:08 +0800 > When last slave of a bonding master is removed, the bonding then does not > work. > At the time if packet_snd is called against with a master net_device, it calls > then header_ops->create which points to slave's header_ops. In case the slave > is ipoib and the module is unloaded, header_ops would point to invalid > address. > Accessing it will cause problem. > This patch tries to fix this issue by moving ipoib_header_ops to vmlinux to > keep > it valid even when ipoib module is unloaded. > > Signed-off-by: Wengang Wang IPOIB should not work over bonding as it requires that the device use ARPHRD_ETHER. Someone mentioned this, and I did not see any response. Please show how a legitimate real bonding configuration can be created, reproduce a stray memory access, and therefore potentially cause a crash. Using various debugging features of the kernel should allow you to trigger an assertion quite easily if this bug really exists. -- 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 net-next 0/5] RDMA/cxgb4,cxgb4vf,csiostor: Cleanup macros
From: Hariprasad Shenai Date: Fri, 21 Nov 2014 12:52:00 +0530 > This series continues to cleanup all the macros/register defines related to > filter, port, VI, queue, RSS, LDST, firmware, etc that are defined in > t4fw_api.h > and the affected files. > > Will post few more series so that we can cover all the macros so that they all > follow the same style to be consistent. > > The patches series is created against 'net-next' tree. > And includes patches on cxgb4, cxgb4vf, iw_cxgb4 and csiostor driver. > > We have included all the maintainers of respective drivers. Kindly review the > change and let us know in case of any review comments. Series applied, thanks. -- 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: mlx5: don't duplicate kvfree()
From: Al Viro Date: Thu, 20 Nov 2014 08:13:57 + > Signed-off-by: Al Viro Applied. -- 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 net-next] cxgb4i/cxgb4 : Refactor macros to conform to uniform standards
From: Anish Bhatt Date: Wed, 12 Nov 2014 17:15:57 -0800 > Refactored all macros used in cxgb4i as part of previously started cxgb4 macro > names cleanup. Makes them more uniform and avoids namespace collision. > Minor changes in other drivers where required as some of these macros are used > by multiple drivers, affected drivers are iw_cxgb4, cxgb4(vf) & csiostor > > Signed-off-by: Anish Bhatt Applied, thanks. -- 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: [PATCHv3 net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: Hariprasad Shenai Date: Fri, 7 Nov 2014 09:35:22 +0530 > This series moves the debugfs code to a new file debugfs.c and cleans up > macros/register defines. > > Various patches have ended up changing the style of the symbolic > macros/register > defines and some of them used the macros/register defines that matches the > output of the script from the hardware team. > > As a result, the current kernel.org files are a mix of different macro styles. > Since this macro/register defines is used by five different drivers, a > few patch series have ended up adding duplicate macro/register define entries > with different styles. This makes these register define/macro files a complete > mess and we want to make them clean and consistent. > > Will post few more series so that we can cover all the macros so that they all > follow the same style to be consistent. > > The patches series is created against 'net-next' tree. > And includes patches on cxgb4, cxgb4vf, iw_cxgb4, csiostor and cxgb4i driver. > > We have included all the maintainers of respective drivers. Kindly review the > change and let us know in case of any review comments. ... > V3: Use suffix instead of prefix for macros/register defines > V2: Changes the description and cover-letter content to answer David Miller's > question Series applied, thanks. -- 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: [PATCHv2 net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: Hariprasad S Date: Thu, 6 Nov 2014 21:45:10 +0530 > On Wed, Nov 05, 2014 at 14:54:43 -0500, David Miller wrote: >> From: Hariprasad Shenai >> Date: Tue, 4 Nov 2014 08:20:54 +0530 >> >> > It's not really the "hardware" which generates these hardware constant >> > symbolic >> > macros/register defines of course, it's scripts developed by the hardware >> > team. >> > Various patches have ended up changing the style of the symbolic >> > macros/register >> > defines and some of them used the macros/register defines that matches the >> > output of the script from the hardware team. >> >> We've told you that we don't care what format your internal whatever uses >> for these macros. >> >> We have standards, tastes, and desires and reasons for naming macros >> in a certain way in upstream kernel code. >> >> I consider it flat out unacceptable to use macros with one letter >> prefixes like "S_". You simply should not do this. >> > > Okay. We’ll clean up all of the macros to match the files' original style. We > do need to change the sense of the *_MASK macros since they don’t match how > we > use them as field tokens. Also the *_SHIFT, *_MASK and *_GET names are > sucking up space and making lines wrap unnecessarily, creating readability > problems. Can we change these to *_S, *_M and *_G? E.g.: That's fine.
Re: [PATCH net 0/2] mlx5_core fixes for 3.18
From: Eli Cohen Date: Thu, 6 Nov 2014 12:51:20 +0200 > the following two patches fix races to could lead to kernel panic in some > cases. Series applied, thanks Eli. -- 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: [PATCHv2 net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: Hariprasad Shenai Date: Tue, 4 Nov 2014 08:20:54 +0530 > It's not really the "hardware" which generates these hardware constant > symbolic > macros/register defines of course, it's scripts developed by the hardware > team. > Various patches have ended up changing the style of the symbolic > macros/register > defines and some of them used the macros/register defines that matches the > output of the script from the hardware team. We've told you that we don't care what format your internal whatever uses for these macros. We have standards, tastes, and desires and reasons for naming macros in a certain way in upstream kernel code. I consider it flat out unacceptable to use macros with one letter prefixes like "S_". You simply should not do this. Why? Because you are polluting the global name space, that's why. You should only define macros with very-likely-to-be-unique prefixes otherwise you and some arch/* header file are going to define the same thing. This is not just theory, it has happened in the past. I'm not applying this series, fixup your macros properly. And to repeat, complaints about how your internal tools generate things will fall on deaf ears. Thanks. -- 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 net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: Hariprasad Shenai Date: Mon, 3 Nov 2014 17:46:51 +0530 > This series moves the debugfs code to a new file debugfs.c, Cleans up macros > so > that they match the hardware generated one. How does "hardware generate the macros"? I don't understand what this means at all. Whatever your better explanation is, you'll have include it in a respun version of this patch series. Thanks. -- 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: 3.17-rc1 oops during network interface configuration
From: Or Gerlitz
Date: Wed, 10 Sep 2014 10:42:41 +0300
> Hi Chuck, thanks for bisecting this out. Indeed, as of this kernel 3.2
> commit 936d7de "IPoIB: Stop lying about hard_header_len and use
> skb->cb to stash LL addresses" we are using the skb->cb field to
> enable proper work under GRO and avoid another historical quirk we had
> there... so I think we can definetly consider commit e0f31d849 to
> introduce a severe regression... Govindarajulu, Dave - what's your
> thinking here? any quick idea on how to fix?
Eric mentioned that we could reduce the amount of flow state stored
in the qdisc cb in order to handle this better.
Making skb->cb[] larger is basically out of the question as far as
I'm concerned.
> Also, I was thinking we have the mechanics in the kernel, e.g commit
> a0417fa3a18a ("net: Make qdisc_skb_cb upper size bound explicit.") to
> catch such over-flows?
Yes we should have added a build-time check so that we would discover
this issue more quickly.
--
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 0/5] Misc. fix for cxgb4 and iw_cxgb4
From: Hariprasad Shenai
Date: Mon, 21 Jul 2014 20:55:11 +0530
> This patch series adds support to enchance error reporting, log detailed
> warning for negative advice, support query_qp verb and advertise correct
> device max attributes for iwarp.
>
> The patches series is created against 'net-next' tree.
> And includes patches on cxgb4 and iw_cxgb4 driver.
>
> Since this patch-series contains changes which are dependent on commit id
> 4c2c5763 ("cxgb4/iw_cxgb4: use firmware ord/ird resource limits") of net-next
> tree we would like to request this patch series to get merged via David
> Miller's
> 'net-next' tree.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
Series applied to net-next, thanks.
--
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 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use
From: Benoit Taine Date: Fri, 18 Jul 2014 17:26:47 +0200 > We should prefer `const struct pci_device_id` over > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. > This issue was reported by checkpatch. > > A simplified version of the semantic patch that makes this change is as > follows (http://coccinelle.lip6.fr/): > > // > > @@ > identifier i; > declarer name DEFINE_PCI_DEVICE_TABLE; > initializer z; > @@ > > - DEFINE_PCI_DEVICE_TABLE(i) > + const struct pci_device_id i[] > = z; > > // > > I have 103 patches ready, and will only send a few for you to judge if > it is useful enough, and to prevent from spamming too much. I'm fine with this wrt. the networking changes, but I don't think this should be merged via my tree. -- 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] iw_cxgb4: fix for 64-bit integer division
From: Sergei Shtylyov
Date: Thu, 17 Jul 2014 22:44:42 +0400
> Hello.
>
> On 07/17/2014 09:01 PM, Hariprasad Shenai wrote:
>
>> Fixed error introduced in commit id 7730b4c (" cxgb4/iw_cxgb4: work
>> request
>> logging feature") while compiling on 32 bit architecture reported by
>> kbuild.
>
>> Signed-off-by: Hariprasad Shenai
>> ---
>> drivers/infiniband/hw/cxgb4/device.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>> diff --git a/drivers/infiniband/hw/cxgb4/device.c
>> b/drivers/infiniband/hw/cxgb4/device.c
>> index df1f1b5..bb0de61 100644
>> --- a/drivers/infiniband/hw/cxgb4/device.c
>> +++ b/drivers/infiniband/hw/cxgb4/device.c
> [...]
>> @@ -150,7 +151,7 @@ static int wr_log_show(struct seq_file *seq, void
>> *v)
>> int prev_ts_set = 0;
>> int idx, end;
>>
>> -#define ts2ns(ts) ((ts) * dev->rdev.lldi.cclk_ps / 1000)
>> +#define ts2ns(ts) div64_ul((ts) * dev->rdev.lldi.cclk_ps , 1000)
>
>Don't need space before comma.
I killed the space when applying this patch, thanks everyone.
--
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 net-next v2 0/4] cxgb4i: Add ipv6 support
From: Anish Bhatt Date: Thu, 17 Jul 2014 00:18:14 -0700 >The following patchset add ipv6 support for the cxgb4i(iscsi) driver. > > Patch 1 moves a define from the iw_cxgb4 to cxgb4 to prevent code duplication, > as it is used by cxgb4i and iw_cxgb4 both. > Patch 2 exports symbols needed by cxgb4i for ipv6 support from cxgb4. > Patch 3 & 4 deal with actual ipv6 code in libcxgbi/cxgb4i. > > Submitting to net-next as changes were needed in cxgb4/iw_cxgb4, and > submitting > to scsi separately would break compilation, cc-ing scsi & rdma. > > v2 : Cleanup macro that prints ip addresses by using %pIS in patch 3 Series applied, thanks. -- 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 net-next 3/4] libcxgbi: Add ipv6 api to driver
From: Anish Bhatt Date: Tue, 15 Jul 2014 19:55:52 -0700 > +#define pr_info_ipaddr(fmt_trail,\ > + addr1, addr2, args_trail...)\ Barf... use "%pIS" instead, which takes a pointer to a sockaddr of family AF_INET or AF_INET6. -- 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: [PATCHv2 net-next 0/4] Misc. fixes for iw_cxgb4
From: Hariprasad Shenai
Date: Mon, 14 Jul 2014 21:34:50 +0530
> This patch series adds support to determine ingress padding boundary at
> runtime.
> Advertise a larger max read queue depth for qps, and gather the resource
> limits
> from fw and use them to avoid exhausting all the resources and display TPTE on
> errors and add support for work request logging feature.
>
> The patches series is created against 'net-next' tree.
> And includes patches on cxgb4 and iw_cxgb4 driver.
>
> Since this patch-series contains changes which are dependent on commit id
> fc5ab02 ("cxgb4: Replaced the backdoor mechanism to access the HW memory with
> PCIe Window method") we would like to request this patch series to get merged
> via David Miller's 'net-next' tree.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
>
> V2:
> Optimized alloc_ird function, and several other changes related to debug
> prints
> based on review comments given by Yann Droneaud.
Series applied to net-next, thanks.
--
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 0/5] cxgb4: Fix for PCI passthrough and some Misc. fixes
From: Hariprasad Shenai Date: Fri, 27 Jun 2014 19:23:46 +0530 > This patch series fixes probe failure in VM when PF is exposed through PCI > Passthrough. Adds support to use firmware interface to get BAR0 value. > Replace the backdoor mechanism to access the HW memory with PCIe Window method > which fixes memory I/O. Also adds device ID of few more adapters for cxgb4 and > cxgb4vf driver. > > The patches series is created against 'net-next' tree. > And includes patches on cxgb4, cxgb4vf and iw_cxgb4 driver. > > Since this patch-series contains mainly cxgb4 related changes, we would like > to > request this patch series to get merged via David Miller's 'net-next' tree. > > We have included all the maintainers of respective drivers. Kindly review the > change and let us know in case of any review comments. Series applied, thanks. -- 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 00/22] Add and use pci_zalloc_consistent
From: Joe Perches Date: Mon, 23 Jun 2014 06:41:28 -0700 > Adding the helper reduces object code size as well as overall > source size line count. > > It's also consistent with all the various zalloc mechanisms > in the kernel. > > Done with a simple cocci script and some typing. For networking bits: Acked-by: David S. Miller -- 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 net-next 0/4] Adds support for CIQ and other misc. fixes for rdma/cxgb4
From: Hariprasad Shenai Date: Fri, 6 Jun 2014 21:40:41 +0530 > This patch series adds support to allocate and use IQs specifically for > indirect interrupts, adds fixes to align ISS for iWARP connections & fixes > related to tcp snd/rvd window for Chelsio T4/T5 adapters on iw_cxgb4. > Also changes Interrupt Holdoff Packet Count threshold of response queues for > cxgb4 driver. > > The patches series is created against 'net-next' tree. > And includes patches on cxgb4 and iw_cxgb4 driver. > > Since this patch-series contains cxgb4 and iw_cxgb4 patches, we would like to > request this patch series to get merged via David Miller's 'net-next' tree. > > We have included all the maintainers of respective drivers. Kindly review the > change and let us know in case of any review comments. Series applied, thanks. -- 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] drivers: net: ethernet: mellanox: mlx4: let mlx4 depend on SMP
From: Chen Gang Date: Sat, 17 May 2014 13:26:16 +0800 > 'struct irq_affinity_notify' and the related functions are only defined > when SMP enabled, so at present, mlx4 has to only run under SMP. > > The related error (allmodconfig under unicore32): Making the entire driver depend upon SMP is not the answer, other Mellanox developers said that a proper fix is pending so please be patient. -- 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] [resend] net: get rid of SET_ETHTOOL_OPS
From: Wilfried Klaebe Date: Sun, 11 May 2014 00:12:32 + > net: get rid of SET_ETHTOOL_OPS > > Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. > This does that. > > Mostly done via coccinelle script: > @@ > struct ethtool_ops *ops; > struct net_device *dev; > @@ > - SET_ETHTOOL_OPS(dev, ops); > + dev->ethtool_ops = ops; > > Compile tested only, but I'd seriously wonder if this broke anything. > > Suggested-by: Dave Miller > Signed-off-by: Wilfried Klaebe Applied to net-next, thanks. -- 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 V2] mellanox: Logging message cleanups
From: Joe Perches Date: Wed, 7 May 2014 12:52:57 -0700 > Use a more current logging style. > > o Coalesce formats > o Add missing spaces for coalesced formats > o Align arguments for modified formats > o Add missing newlines for some logging messages > o Use DRV_NAME as part of format instead of %s, DRV_NAME to > reduce overall text. > o Use ..., ##__VA_ARGS__ instead of args... in macros > o Correct a few format typos > o Use a single line message where appropriate > > Signed-off-by: Joe Perches > Acked-By: Amir Vadai Applied, thanks. -- 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] mellanox: Logging message cleanups
Joe, please get rid of the initial empty line you're adding to fw.c and resubmit with Amir's ACK. Thanks. -- 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 0/3] Hangs with IPoIB when doing PCI error injection
From: cls...@linux.vnet.ibm.com Date: Thu, 27 Mar 2014 09:28:13 -0500 > This patch is to resolve some hangs we are seeing when doing PCI error > injection > to Mellanox Infiniband cards. With this patch we make mlx4 driver send an > IB_EVENT_DEVICE_FATAL > to the users and added this event to event handlers to avoid these hangs. > If IPoIB is in connected mode, then added to cm an event handler and tried to > make sure that when it sees the fatal event it does not try to send anymore > packet because > it will not receive any more completions or interrupts. I'm assuming Roland will take this in via his tree. Thanks. -- 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] RDMA/cxgb4: set error code on kmalloc() failure
From: "Steve Wise" Date: Wed, 26 Mar 2014 10:25:22 -0500 > Acked-by: Steve Wise > > Note: This fix applies only to net-next because the commit that introduced > this is still > pending in net-next: > > commit 05eb23893c2cf9502a9cec0c32e7f1d1ed2895c8 > Author: Steve Wise > Date: Fri Mar 14 21:52:08 2014 +0530 > > cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes > > > Dave, can you please merge this? Done, thanks. -- 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 net-next 0/2] Doorbell drop Avoidance Bug fix for iw_cxgb4
From: Hariprasad Shenai Date: Fri, 14 Mar 2014 21:52:06 +0530 > This patch series provides fixes for Chelsio T4/T5 adapters > related to DB Drop avoidance and other small fix related to keepalive on > iw-cxgb4. > > The patches series is created against David Miller's 'net-next' tree. > And includes patches on cxgb4 and iw_cxgb4 driver. > > We would like to request this patch series to get merged via David Miller's > 'net-next' tree. > > We have included all the maintainers of respective drivers. Kindly review the > change and let us know in case of any review comments. Series applied, thanks. -- 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: [PATCHv6 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4
From: Casey Leedom Date: Wed, 12 Mar 2014 16:43:33 -0700 > Should we revisit that decision and ask Hari to submit a series of > much smaller patch sets (one at a time obviously)? That might be a good idea, honestly. -- 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: [PATCHv6 net-next 20/31] iw_cxgb4: adjust tcp snd/rcv window based on link speed
From: "Steve Wise" Date: Wed, 12 Mar 2014 16:29:27 -0500 >> >> You can just use the TCP settings the kernel already provides for >> >> the real TCP stack. >> > >> > Do you mean use sysctl_tcp_*mem, sysctl_tcp_timestamps, >> > sysctl_tcp_window_scaling, > etc? >> > I'll look into this. >> >> And the socket memory limits, which we use to compute default window >> sizes. > > How's this look (compile-tested only)? Note I had to export some of the tcp > limits. Well, the problem is that you've dug your own hole already. You can't just remove these existing module parameters that users can set. They are user visible APIs, you can't just remove them. The best you can do is stop adding new ones. -- 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: [PATCHv6 net-next 20/31] iw_cxgb4: adjust tcp snd/rcv window based on link speed
From: "Steve Wise" Date: Wed, 12 Mar 2014 15:08:33 -0500 >> > Added module option named adjust_win, defaulted to 1, that allows >> > disabling the 40G window bump. This allows a user to specify the exact >> > default window sizes via module options snd_win and rcv_win. >> >> This is terrible. As is the existing other TCP tweaking module >> parameters. >> >> You can just use the TCP settings the kernel already provides for >> the real TCP stack. > > Do you mean use sysctl_tcp_*mem, sysctl_tcp_timestamps, > sysctl_tcp_window_scaling, etc? > I'll look into this. And the socket memory limits, which we use to compute default window sizes. -- 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: [PATCHv6 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4
From: Hariprasad Shenai Date: Wed, 12 Mar 2014 21:20:15 +0530 > V6: >In patch 8/31, move the existing neigh_release() call right before the >if(!e) test, that way you don't need a completely new label and code block >to fix this bug - thanks to review by David Miller >In patch 15/31, use %pad to print dma_addr - thanks to review by Joe > Perches >In patch 10/31, add the "STOPPED" state string to db_state_str - thanks >to review by Steve Wise >In patch 10/31, t4_db_dropped() needs to disable dbs and send DB_FULL >event to iw_cxgb4 - thanks to review by Steve Wise > V5: >Dropped patch "cxgb4: use spinlock_irqsave/spinlock_irqrestore for db > lock". I do not see the spinlock patch reinstated, part of it was correct and fixed a real bug. For the second time, I only stated that parts of it were superfluous, not all of it. This is becomming beyond tiring. -- 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: [PATCHv6 net-next 20/31] iw_cxgb4: adjust tcp snd/rcv window based on link speed
From: Hariprasad Shenai Date: Wed, 12 Mar 2014 21:20:35 +0530 > Added module option named adjust_win, defaulted to 1, that allows > disabling the 40G window bump. This allows a user to specify the exact > default window sizes via module options snd_win and rcv_win. This is terrible. As is the existing other TCP tweaking module parameters. You can just use the TCP settings the kernel already provides for the real TCP stack. -- 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] IB/mlx5_core: remove unreachable function call in module init
From: Kleber Sacilotto de Souza Date: Fri, 7 Mar 2014 19:48:25 -0300 > The call to mlx5_health_cleanup() in the module init function can never > be reached. Removing it. > > Signed-off-by: Kleber Sacilotto de Souza Applied to net-next, thank you. -- 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: [PATCHv5 net-next 08/31] iw_cxgb4: release neigh entry in error paths
From: Hariprasad Shenai
Date: Mon, 10 Mar 2014 22:38:05 +0530
> diff --git a/drivers/infiniband/hw/cxgb4/cm.c
> b/drivers/infiniband/hw/cxgb4/cm.c
> index 360807e..74a2250 100644
> --- a/drivers/infiniband/hw/cxgb4/cm.c
> +++ b/drivers/infiniband/hw/cxgb4/cm.c
> @@ -3350,10 +3350,9 @@ static int rx_pkt(struct c4iw_dev *dev, struct sk_buff
> *skb)
> if (!e) {
> pr_err("%s - failed to allocate l2t entry!\n",
> __func__);
> - goto free_dst;
> + goto free_neigh;
> }
>
> - neigh_release(neigh);
> step = dev->rdev.lldi.nrxq / dev->rdev.lldi.nchan;
> rss_qid = dev->rdev.lldi.rxq_ids[pi->port_id * step];
> window = (__force u16) htons((__force u16)tcph->window);
> @@ -3373,6 +3372,8 @@ static int rx_pkt(struct c4iw_dev *dev, struct sk_buff
> *skb)
> tcph->source, ntohl(tcph->seq), filter, window,
> rss_qid, pi->port_id);
> cxgb4_l2t_release(e);
> +free_neigh:
> + neigh_release(neigh);
> free_dst:
It is so much easier to just move the existing neigh_release() call right
before the if(!e) test, that way you don't need a completely new label and
code block to fix this bug.
--
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: [PATCHv5 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4
From: Hariprasad Shenai Date: Mon, 10 Mar 2014 22:37:57 +0530 >Dropped patch "cxgb4: use spinlock_irqsave/spinlock_irqrestore for db > lock". >save/restore spinlock variants are not required - thanks to review by >David Miller. That is absolutely not what I said. I said that specific instances of the transformation were not correct, the rest were and were absolutely necessary. Reviewing this series is starting to feel like a complete waste of my time. -- 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: [PATCHv4 net-next 05/32] cxgb4: use spinlock_irqsave/spinlock_irqrestore for db lock
From: Hariprasad Shenai
Date: Fri, 7 Mar 2014 16:03:02 +0530
> @@ -3585,9 +3585,11 @@ static void disable_txq_db(struct sge_txq *q)
>
> static void enable_txq_db(struct sge_txq *q)
> {
> - spin_lock_irq(&q->db_lock);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&q->db_lock, flags);
> q->db_disabled = 0;
> - spin_unlock_irq(&q->db_lock);
> + spin_unlock_irqrestore(&q->db_lock, flags);
> }
>
> static void disable_dbs(struct adapter *adap)
> @@ -3617,9 +3619,10 @@ static void enable_dbs(struct adapter *adap)
At least be consistent when making changes like this.
You are changing from spin_{un,}lock_irq() to
spin_{un,}lock_irq{save,restore}() here in enable_txq_db()
but not in disable_txq_db().
But both of those functions are invoked, via one level of
indirection, from the same exact function: process_db_drop()
Futhermore, this function process_db_drop() runs via a workqueue, and
therefore always runs with interrupts enabled. So you shouldn't need
to use the save/restore spinlock variants at all. Plain
spin_lock_irq() and spin_unlock_irq(), as is currently coded, is
perfectly fine.
--
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: [PATCHv3 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4
BTW, if you're frustrated from having to send these patches so many times because of changes being requested, this is the main reason why you shouldn't queue up such enormous numbers of patches at one time. Please try to keep your future submissions sizes more reasonable, perhaps ~10 patches or so at most. Thanks. -- 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 net-next 10/31] cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes.
From: "Steve Wise" Date: Thu, 27 Feb 2014 11:11:49 -0600 >> >> > -static int allow_db_fc_on_t5; >> > -module_param(allow_db_fc_on_t5, int, 0644); >> > -MODULE_PARM_DESC(allow_db_fc_on_t5, >> > - "Allow DB Flow Control on T5 (default = 0)"); >> > - >> > -static int allow_db_coalescing_on_t5; >> > -module_param(allow_db_coalescing_on_t5, int, 0644); >> > -MODULE_PARM_DESC(allow_db_coalescing_on_t5, >> > - "Allow DB Coalescing on T5 (default = 0)"); >> >> Module parameters are a user facing interface. >> >> You cannot just delete, or change the semantics of, the ones you feel >> like doing so to. > > I see your point on user facing interfaces. These module params were > added initially to allow tweaking the db drop recovery for T5 devices in > the thought that we might need it. It turns out T5 doesn't suffer from > this issue. These params default to 0 anyway, and I doubt anyone has > changed them. Disabling the hw db coalescing feature proved problematic > and it turned out to even make the issue worse, so I removed it totally > at the recommendation from the HW engineers, and put in place the new > design which better rate controls things under heavy load. You have to keep the old ones around. -- 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 net-next 10/31] cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes.
From: Hariprasad Shenai Date: Wed, 26 Feb 2014 20:36:49 +0530 > -static int allow_db_fc_on_t5; > -module_param(allow_db_fc_on_t5, int, 0644); > -MODULE_PARM_DESC(allow_db_fc_on_t5, > - "Allow DB Flow Control on T5 (default = 0)"); > - > -static int allow_db_coalescing_on_t5; > -module_param(allow_db_coalescing_on_t5, int, 0644); > -MODULE_PARM_DESC(allow_db_coalescing_on_t5, > - "Allow DB Coalescing on T5 (default = 0)"); Module parameters are a user facing interface. You cannot just delete, or change the semantics of, the ones you feel like doing so to. -- 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: net,IB/mlx: Bump all Mellanox driver versions
From: Amir Vadai Date: Wed, 19 Feb 2014 18:23:18 +0200 > On 19/02/14 17:47 +0200, Amir Vadai wrote: >> Bump all Mellanox driver versions. >> >> Signed-off-by: Amir Vadai >> --- >> Hi, >> >> We're changing the version scheme of our drivers. >> I would be happy if it goes to net. Also, added here drivers from rdma tree, >> because I would like it to be unified accorss all Mellanox's drivers. ... > Adding linux-rdma and Roland to the CC Applied to 'net', thanks. -- 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 net-next 00/35] net: Use pci_enable_msix_range() instead of pci_enable_msix()
From: Alexander Gordeev Date: Tue, 18 Feb 2014 11:07:52 +0100 > As result of deprecation of MSI-X/MSI enablement functions > pci_enable_msix() and pci_enable_msi_block() all drivers > using these two interfaces need to be updated to use the > new pci_enable_msi_range() and pci_enable_msix_range() > interfaces. > > Cc: e1000-de...@lists.sourceforge.net > Cc: linux-dri...@qlogic.com > Cc: linux-net-driv...@solarflare.com > Cc: linux-...@vger.kernel.org > Cc: linux-rdma@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: pv-driv...@vmware.com > Cc: wil6...@qca.qualcomm.com Series applied, thanks. -- 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 net v2 0/8] Fixes for server entries and server filter entries for Chelsio T4/T5
From: Hariprasad Shenai Date: Wed, 18 Dec 2013 16:38:18 +0530 > This patch series provides miscelleneous fixes for Chelsio T4/T5 adapters > related to server entries and server filter entries. Series applied, thanks. -- 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 net 0/9] Fixes for server entries and server filter entries for Chelsio T4/T5
From: Hariprasad Shenai Date: Mon, 16 Dec 2013 17:42:09 +0530 > This patch series provides miscelleneous fixes for Chelsio T4/T5 adapters > related to server entries and server filter entries. You add the sftids_in_use counter, but it is never tested by any code. It is only initialized to zero, incremented, and decremented. It serves no real purpose at all. Please don't add things like this. -- 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 for-next] mlx4_core: Roll back round robin bitmap allocation commit for CQs, SRQs, and MPTs
From: Or Gerlitz Date: Sun, 8 Dec 2013 16:50:17 +0200 > From: Jack Morgenstein > > Commit f4ec9e9 "mlx4_core: Change bitmap allocator to work in round-robin > fashion" > introduced round-robin allocation (via bitmap) for all resources which > allocate > via a bitmap. > > Round robin allocation is desirable for mcgs, counters, pd's, UARs, and xrcds. > These are simply numbers, with no involvement of ICM memory mapping. > > Round robin is required for QPs, since we had a problem with immediate > reuse of a 24-bit QP number (commit f4ec9e9). > > However, for other resources which use the bitmap allocator and involve > mapping ICM memory -- MPTs, CQs, SRQs -- round-robin is not desirable. > > What happens in these cases is the following: > > ICM memory is allocated and mapped in chunks of 256K. > > Since the resource allocation index goes up monotonically, the allocator > will eventually require mapping a new chunk. Now, chunks are also unmapped > when their reference count goes back to zero. Thus, if a single app is > running and starts/exits frequently we will have the following situation: > > When the app starts, a new chunk must be allocated and mapped. > > When the app exits, the chunk reference count goes back to zero, and the > chunk is unmapped and freed. Therefore, the app must pay the cost of > allocation > and mapping of ICM memory each time it runs (although the price is paid only > when > allocating the initial entry in the new chunk). > > For apps which allocate MPTs/SRQs/CQs and which operate as described above, > this presented a performance problem. > > We therefore roll back the round-robin allocator modification for MPTs, CQs, > SRQs. > > Reported-by: Matthew Finlay > Signed-off-by: Jack Morgenstein > Signed-off-by: Or Gerlitz Applied, thanks. -- 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 v2] mlx5_core: delete some dead code
From: Dan Carpenter Date: Tue, 5 Nov 2013 01:20:56 +0300 > The printk() looks like it is left over debug code. I have removed it. > > Signed-off-by: Dan Carpenter > --- > v2: Remove the printk instead of moving it infront of the return. This doesn't apply to the current tree, I suspect some recent changes made this fix no longer applicable. Please take a look. Thanks! -- 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] mlx5: remove unused MLX5_DEBUG param in Kconfig
From: Michael Opdenacker Date: Fri, 6 Sep 2013 13:49:22 +0200 > This patch proposes to remove the MLX5_DEBUG kernel configuration > parameter defined in drivers/net/ethernet/mellanox/mlx5/core/Kconfig, > but used nowhere in the makefiles and source code. > > This could also be fixed by using this parameter, > but this may be a leftover from driver development... > > Signed-off-by: Michael Opdenacker Applied. -- 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 2/2] fs: use inode_set_user to set uid/gid of inode
From: Rui Xiang Date: Fri, 23 Aug 2013 10:48:38 +0800 > Use the new interface to set i_uid/i_gid in inode struct. > > Signed-off-by: Rui Xiang For the networking bits: Acked-by: David S. Miller -- 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] mlx5: fix error return code in mlx5_alloc_uuars()
From: Wei Yongjun Date: Tue, 30 Jul 2013 07:57:06 +0800 > From: Wei Yongjun > > Fix to return -ENOMEM from the ioremap error handling > case instead of 0, as done elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied, thanks. -- 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] mlx5: use after free in mlx5_cmd_comp_handler()
From: Eli Cohen Date: Wed, 24 Jul 2013 19:35:44 +0300 > This race has been spotted and fixed by Moshe Lazer two weeks ago. > Anyways, > > Acked by Eli Cohen Applied. -- 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.11-rc1] mlx5 core: Fix __udivdi3 when compiling for 32 bit arches
From: Randy Dunlap Date: Mon, 15 Jul 2013 08:52:18 -0700 > On 07/15/13 07:56, Tim Gardner wrote: >> Cc: Eli Cohen >> Signed-off-by: Tim Gardner > > I reported this last week and Eli wrote: > > "I have this fixed in my tree and we run the driver on i386. I will check on > Sunday why it is not in the patches submitted." > > Anyway, the patch works for me. > > Acked-by: Randy Dunlap > Reported-by: Randy Dunlap Applied, thanks. -- 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 V2 0/4] Add IPv6 support for iWARP
From: Vipul Pandya Date: Tue, 02 Jul 2013 12:17:57 +0530 > I upgraded my GCC version from 4.4.6-4 to 4.8.1 and after that I am able > to see that warning. I will resubmit this series soon. That's fine, but realize it is too late to submit this for the current merge window. -- 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 for/net-next 3/8] net/mlx5: Mellanox Connect-IB, core driver part 3/3
From: Jack Morgenstein
Date: Mon, 1 Jul 2013 14:44:54 +0300
> On Saturday 29 June 2013 07:10, David Miller wrote:
>> From: Or Gerlitz
>> Date: Wed, 26 Jun 2013 17:22:12 +0300
>>
>> > + for (--i; i >= 0; --i) {
>>
>> Please, "i--" is more canonical in for() loops.
>>
>> > + for (--i; i >= 0; --i) {
>>
>> Likewise.
>> --
>> 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
>>
> Hi Dave,
>
> For the "for" loop initial value, "i" should be decremented before doing any
> for-loop calculations (and it is not at all obvious if this is the ordering
> if we use
> i--, and not --i). Using --i in the initial value makes the ordering obvious.
> However, I do agree with respect to the increment that --i and i-- are
> logically
> identical.
>
> Thus, the "for" loop could read:
> for (--i; i >= 0; i--) {
>
> However, my own personal opinion is that this is a bit confusing.
> I would prefer to leave these lines as they are.
>
> Is that OK with you?
Actually, you should adjust both decrements to read "i--".
Look, if someone doesn't grok that the leftmost decrement happens
before any of the loop body or tests, they don't understand how
for() loops work.
And you're syntax is just confusing people who actually _do_
understand how this part of the C language operates.
--
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 for/net-next 3/8] net/mlx5: Mellanox Connect-IB, core driver part 3/3
From: Jack Morgenstein
Date: Mon, 1 Jul 2013 14:44:54 +0300
> Thus, the "for" loop could read:
> for (--i; i >= 0; i--) {
>
> However, my own personal opinion is that this is a bit confusing.
> I would prefer to leave these lines as they are.
>
> Is that OK with you?
Please adjust the right-most increment.
--
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 for/net-next 3/8] net/mlx5: Mellanox Connect-IB, core driver part 3/3
From: Or Gerlitz
Date: Wed, 26 Jun 2013 17:22:12 +0300
> + for (--i; i >= 0; --i) {
Please, "i--" is more canonical in for() loops.
> + for (--i; i >= 0; --i) {
Likewise.
--
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 for/net-next 2/8] net/mlx5: Mellanox Connect-IB, core driver part 2/3
From: Or Gerlitz
Date: Wed, 26 Jun 2013 17:22:11 +0300
> + eqe->owner = 0x55;
Magic constant. If this is how you will represent "Invalid Owner",
then make a macro for this value 0x55 expressing that.
> + switch (synd) {
> + case 0x1:
Please make descriptive macros instead of using magic constants.
> +#if defined(__LITTLE_ENDIAN)
> + he_in.he = 0x0;
> +#elif defined(__BIG_ENDIAN)
> + he_in.he = 0x80;
> +#else
> +#error Host endianness not defined
> +#endif
This endiannes bit needs a define, rather than just using a magic
constant. And where you define this in a header file, you can do
the CPP ifdefs, rather than here.
--
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 for/net-next 1/8] net/mlx5: Mellanox Connect-IB, core driver part 1/3
From: Or Gerlitz
Date: Wed, 26 Jun 2013 17:22:10 +0300
> + buf->direct.buf = dma_alloc_coherent(&dev->pdev->dev,
> +size, &t, GFP_KERNEL);
...
> + memset(buf->direct.buf, 0, size);
This sequence is "dma_zalloc_coherent()", please use it.
> + i = find_first_bit(pgdir->bitmap, MLX5_DB_PER_PAGE);
> + if (i >= MLX5_DB_PER_PAGE)
> + return -ENOMEM;
> +
> + clear_bit(i, pgdir->bitmap);
You have other synchronizations protecting this bitmap, so you don't
need to use the atomic clear_bit(), please use __clear_bit() instead.
> +
> + set_bit(db->index, db->u.pgdir->bitmap);
Likewise, use __set_bit().
> + u8 own;
> + unsigned long poll_end = jiffies +
> msecs_to_jiffies(MLX5_CMD_TIMEOUT_MSEC + 1000);
I know it sounds silly, but order local variable declarations from longest
to shortest line, it looks a lot nicer.
> +static int verify_signature(struct mlx5_cmd_work_ent *ent)
> +{
> + int err;
> + u8 sig;
> + struct mlx5_cmd_mailbox *next = ent->out->next;
Likewise.
> +static void dump_buf(void *buf, int size, int data_only, int offset)
> +{
> + int i;
> + __be32 *p = buf;
Likewise. Please go over all of this new driver and take care of this,
thanks.
> +static const char *status_to_str(u8 status)
> +{
> + switch (status) {
> + case 0:
> + return "no errors";
Please add defines for these status codes rather than using magic
constants.
> + for (i = 0; i < n; ++i) {
"i++", rather than "++i" is canonical in this situations, please.
> + for (i = 0; i < (1 << cmd->log_sz); ++i) {
Likewise. Please fix this up in all of this driver's code.
> + /*
> + * for cached lists, we must explicitly state what is
> + * the real size
> + */
Comments in the networking are to be formatted:
/* Like
* this.
*/
and not:
/*
* Like
* this.
*/
Please take care of this in the entire driver, thanks.
> +ex_err:
> + list_for_each_entry_safe(msg, n, &cmd->cache.large.head, list) {
> + list_del(&msg->list);
> + mlx5_free_cmd_msg(dev, msg);
> + }
> +
> + list_for_each_entry_safe(msg, n, &cmd->cache.med.head, list) {
> + list_del(&msg->list);
> + mlx5_free_cmd_msg(dev, msg);
> + }
> +
> + return err;
This cleanup code is duplicated...
> +static void destroy_msg_cache(struct mlx5_core_dev *dev)
Here.
Simply declare destroy_msg_cache() earlier and call it, instead
of duplicating all of it's code.
> +static const char *cmd_status_str(u8 status)
> +{
> + switch (status) {
> + case 0x0: return "OK";
Again, make readable defines for these status values, rather than using magic
constants.
> + switch (hdr->status) {
> + case 0x0: return 0;
> + case 0x1: return -EIO;
Likewise.
I also question how useful all of these debugfs facilities are after initial
development. They take up memory even if they are never used.
--
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 for-next 0/8] Add Mellanox mlx5 driver for Connect-IB devices
From: Or Gerlitz Date: Thu, 20 Jun 2013 17:44:49 +0300 > So we skipped netdev in V0, in an attempt to reduce cross > postings... anyway, the mlx5_core driver is similar story as of > mlx4_core. So, if looking forward, for the initial merge to be > simpler, are you OK for both the core and IB driver to go through > Roland's tree? I'd like to see it posted to netdev for review before making any kind of decision like that. Thanks. -- 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 V2 0/4] Add IPv6 support for iWARP
From: Steve Wise Date: Wed, 19 Jun 2013 21:19:13 -0500 > On 6/19/2013 8:01 PM, David Miller wrote: >> From: Vipul Pandya >> Date: Wed, 12 Jun 2013 17:11:38 +0530 >> >>> We have included all the maintainers of respective drivers. Kindly >>> review the change and let us know in case of any review comments. >> I have not seen anyone review v2 of this patch series. >> > > Reviewed-by: Steve Wise You wrote the first patch, and I bet you didn't even read the code in the cxgb4 driver. So your review is sort of pointless... UNLESS you spotted the obvious bugs in these changes, that would have been interesting. Because NOBODY, and I mean NOBODY, even looked at the build of the cxgb4 changes. Tell me what this does: struct tid_info *t = dev->rdev.lldi.tids; int status = GET_AOPEN_STATUS(ntohl(rpl->atid_status)); + struct sockaddr_in *la = (struct sockaddr_in *)&ep->com.local_addr; + struct sockaddr_in *ra = (struct sockaddr_in *)&ep->com.remote_addr; + struct sockaddr_in6 *la6 = (struct sockaddr_in6 *)&ep->com.local_addr; + struct sockaddr_in6 *ra6 = (struct sockaddr_in6 *)&ep->com.remote_addr; + + ep = lookup_atid(t, atid); Dereferencing 'ep' before initializing it. The compiler complains loudly about this, therefore nobody even looked at the build logs from these changes before submitting them to me. That translates to "don't care", and if the people submitting this code don't care why should I? Sorry, not impressed. I'm seriously going to take my time reviewing any future submissions of these changes, because it's obvious that even the people writing and submitting this code DO NOT CARE. -- 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 V2 0/4] Add IPv6 support for iWARP
From: Vipul Pandya Date: Wed, 12 Jun 2013 17:11:38 +0530 > We have included all the maintainers of respective drivers. Kindly > review the change and let us know in case of any review comments. I have not seen anyone review v2 of this patch series. At least the Infiniband maintainer should do so. -- 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 V2 1/4] RDMA/cma: Add IPv6 support for iWARP.
From: "Nikolova, Tatyana E" Date: Wed, 12 Jun 2013 19:56:37 + > I reviewed the iWarp IPv6 nes patch. Can you please not top-post and quote the entire patch like this? -- 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/4] RDMA/cma: Add IPv6 support for iWARP.
Please use local variables for the sockaddr_in{,6} pointers instead of
casting over and over and over and over again.
Thanks.
--
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 v2 0/5] tipc: add TIPC over Infiniband support
From: Patrick McHardy Date: Wed, 17 Apr 2013 18:18:24 +0200 > The following patchset adds support for running TIPC over InfiniBand. > The patchset consists of three parts (+ a minor fix for the ethernet media > type): > > - Preparation: removal of an the unused str2addr callback and move of the > bcast_addr from struct tipc_media to struct tipc_bearer. This is necessary > because InfiniBand doesn't have a fixed broadcast address like ethernet, > so it needs to be initialized with the device's broadcast address when > the bearer is enabled > > - Introduction of a TIPC InfiniBand media type. A new media type is needed > to deal with the different address sizes > > - Support for ETH_P_TIPC in IPoIB > > Since the last posting I've addressed all feedback I received and rebased > to the current net-next tree. > > I consider these patches ready for merging. Since they mainly affect TIPC > code, I'd propose to have them either go through the TIPC tree or through > Dave directly (not sure how TIPC patches are managed). All applied to net-next, thanks! -- 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 v2 net-next 00/22] Add support for Chelsio T5 adapter
From: Vipul Pandya Date: Thu, 14 Mar 2013 20:38:46 +0530 > We request to merge this patch series via David Miller's net-next tree. We are > copying respective maintainers of all the drivers for reviewing the changes. > Kindly let us know in case of any review comments. All applied to net-next, thanks. -- 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 net-next 05/22] cxgb4: Add T5 write combining support
From: Vipul Pandya
Date: Tue, 12 Mar 2013 17:16:17 +0530
> + writel(n, adap->bar2 + q->udb + 8);
> +#if defined(CONFIG_X86_32) || defined(CONFIG_X86_64)
> + asm volatile("sfence" : : : "memory");
> +#endif
There is absolutely no way I'm letting anyone put crap like this
into a driver.
Use a portable inteface, and if one does not exist create one.
--
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 net-next V6 00/15] net: introduce upper device lists and remove dev->master
From: Jiri Pirko Date: Fri, 4 Jan 2013 09:48:48 +0100 > This patchset adds a possibility to record upper device linkage. > All upper<->lower devices are converted to use this mechanism right after. > That leads to dev->master removal because this info becomes redundant since > "master links" have the same value. Series applied, thanks Jiri. -- 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/2] IB/rds: Correct ib_api use with gs_dma_address/sg_dma_len
From: Bart Van Assche Date: Tue, 25 Dec 2012 13:10:56 +0100 > The above patch will slow down RDS for anyone who is not using QLogic > HCA's, isn' it ? How about replacing the above patch with the > (untested) patch below ? I agree with your suggestion but do this kind of simplification in the next merge window, not now. That's why I applied Mike's patches as-is. -- 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 2/2] IB/rds: suppress incompatible protocol when version is known
From: Mike Marciniszyn Date: Fri, 21 Dec 2012 13:01:54 -0500 > Add an else to only print the incompatible protocol message > when version hasn't been established. > > Signed-off-by: Mike Marciniszyn Applied. -- 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/2] IB/rds: Correct ib_api use with gs_dma_address/sg_dma_len
From: Mike Marciniszyn
Date: Fri, 21 Dec 2012 13:01:49 -0500
> 0b088e00 ("RDS: Use page_remainder_alloc() for recv bufs")
> added uses of sg_dma_len() and sg_dma_address(). This makes
> RDS DOA with the qib driver.
>
> IB ulps should use ib_sg_dma_len() and ib_sg_dma_address
> respectively since some HCAs overload ib_sg_dma* operations.
>
> Signed-off-by: Mike Marciniszyn
Applied.
--
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: [FIXES for-next 0/4] mlx4_core SRIOV and Flow-Steering adjustments and fixes
These changes only touch the drivers/net/ driver, why are you trying to submit them via the RDMA tree instead of the networking tree? -- 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 V3 1/5] cxgb4: Add T4 filter support
From: Vipul Pandya Date: Mon, 3 Dec 2012 16:52:57 +0530 > + /* > + * If the new or old filter have loopback rewriteing rules then we'll > + * need to free any existing Layer Two Table (L2T) entries of the old > + * filter rule. The firmware will handle freeing up any Source MAC > + * Table (SMT) entries used for rewriting Source MAC Addresses in > + * loopback rules. > + */ > + if (f->l2t) > + cxgb4_l2t_release(f->l2t); > + > + /* The zeroing of the filter rule below clears the filter valid, > + * pending, locked flags, l2t pointer, etc. so it's all we need for > + * this operation. > + */ My greatest amusement is achieved when someone gets a code formatting rule both correct and wrong in the same patch, as you have done here. Format comments in the networking: /* Like * this. */ /* * Never, * like this. */ Thanks. -- 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 V2 1/5] cxgb4: Add T4 filter support
From: Roland Dreier Date: Fri, 30 Nov 2012 17:43:27 -0800 > On Fri, Nov 30, 2012 at 8:56 AM, David Miller wrote: >> I really don't understand how we're supposed to review your patches >> when you only post some parts of the patch series to netdev, and >> others not. > > I think he just didn't repost the patches that were unchanged from the > first time around. Well, he needs to. -- 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 V2 1/5] cxgb4: Add T4 filter support
I really don't understand how we're supposed to review your patches when you only post some parts of the patch series to netdev, and others not. Please do not do this. -- 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 v4 2/2] infiniband: pass rdma_cm module to netlink_dump_start
From: Gao feng Date: Fri, 5 Oct 2012 14:15:49 +0800 > set netlink_dump_control.module to avoid panic. > > Signed-off-by: Gao feng > Cc: Roland Dreier > Cc: Sean Hefty Applied. -- 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
