Re: [PATCHv3 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4
On Wed, Mar 05, 2014 at 17:58:19 -0600, Steve Wise wrote: 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. Sure, thanks for the suggestion. I will just re-post the revert patch on cxgb4 now, part of this series, which is causing regression. And, I will split the rest of patch-series into 8-10 patches and re-submit. I think you should keep this series as-is since folks have been reviewing it as such. Then going forward, we need to submit smaller sets more frequently... Steve. OK.. -Hari -- 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
On 04/03/2014 14:41, Hariprasad Shenai wrote: Hariprasad Shenai (1): Revert cxgb4: Don't assume LSO only uses SGL path in t4_eth_xmit() Kumar Sanghvi (5): cxgb4: Fix some small bugs in t4_sge_init_soft() when our Page Size is 64KB cxgb4: Add code to dump SGE registers when hitting idma hangs cxgb4: Rectify emitting messages about SGE Ingress DMA channels being potentially stuck cxgb4: Updates for T5 SGE's Egress Congestion Threshold cxgb4: use spinlock_irqsave/spinlock_irqrestore for db lock. Steve Wise (25): iw_cxgb4: cap CQ size at T4_MAX_IQ_SIZE. iw_cxgb4: Allow loopback connections. iw_cxgb4: release neigh entry in error paths. iw_cxgb4: Treat CPL_ERR_KEEPALV_NEG_ADVICE as negative advice. cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes. iw_cxgb4: use the BAR2/WC path for kernel QPs and T5 devices. iw_cxgb4: Fix incorrect BUG_ON conditions. iw_cxgb4: Mind the sq_sig_all/sq_sig_type QP attributes. iw_cxgb4: default peer2peer mode to 1. iw_cxgb4: save the correct map length for fast_reg_page_lists. iw_cxgb4: don't leak skb in c4iw_uld_rx_handler(). iw_cxgb4: fix possible memory leak in RX_PKT processing. iw_cxgb4: ignore read reponse type 1 CQEs. iw_cxgb4: connect_request_upcall fixes. iw_cxgb4: adjust tcp snd/rcv window based on link speed. iw_cxgb4: update snd_seq when sending MPA messages. iw_cxgb4: lock around accept/reject downcalls. iw_cxgb4: drop RX_DATA packets if the endpoint is gone. iw_cxgb4: rx_data() needs to hold the ep mutex. iw_cxgb4: endpoint timeout fixes. iw_cxgb4: rmb() after reading valid gen bit. iw_cxgb4: wc_wmb() needed after DB writes. iw_cxgb4: SQ flush fix. iw_cxgb4: minor fixes iw_cxgb4: Max fastreg depth depends on DSGL support. Also, not sure if this is addressed by the coding style or patch submission guide, but I think the common/proper way to set subject (title) line for kernel patches is to avoid a period in the end of the sentence, since this is single line. Anyway, you were not consistent about this tiny detail... some patches subject line end with period some don't, I vote to remove... -- 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
Yes, thanks mightily for your help and advice and sorry for the size of the updates. Hari has taken on the very difficult task of synchronizing our out-of-kernel development branch with the in-kernel code. These two code bases have drifted apart quite a bit because of the difficulty of translating our out-of-kernel changes into the in-kernel driver which uses completely different symbolic register constants. This has led many of us to defer propagating our out-of-kernel work into the in-kernel driver — partly because of the difficulty and party because of the error prone nature of the effort: there are many symbolic register constants which have the exact same name but have completely different values which has tripped us up at least twice, introducing bugs into the kernel.org driver. If there’s ever an opportunity to revisit the decision to have us use these different constants we would be Very Excited … :-) Casey On Mar 4, 2014, at 9:30 PM, Hariprasad S haripra...@chelsio.com wrote: On Tue, Mar 04, 2014 at 13:22:26 -0500, David Miller wrote: 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. Sure, thanks for the suggestion. I will just re-post the revert patch on cxgb4 now, part of this series, which is causing regression. And, I will split the rest of patch-series into 8-10 patches and re-submit. Thanks for the review comments! -Hari. -- 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
On Wed, Mar 5, 2014 at 9:15 PM, Casey Leedom lee...@chelsio.com wrote: Yes, thanks mightily for your help and advice and sorry for the size of the updates. Hari has taken on the very difficult task of synchronizing our out-of-kernel development branch with the in-kernel code. These two code bases have drifted apart quite a bit because of the difficulty of translating our out-of-kernel changes into the in-kernel driver which uses completely different symbolic register constants. Can you explain this in a little bit more details? what's the source of the need to use two different sets of symbolic register constants? -- 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
On Mar 5, 2014, at 11:39 AM, Or Gerlitz or.gerl...@gmail.com wrote: On Wed, Mar 5, 2014 at 9:15 PM, Casey Leedom lee...@chelsio.com wrote: Yes, thanks mightily for your help and advice and sorry for the size of the updates. Hari has taken on the very difficult task of synchronizing our out-of-kernel development branch with the in-kernel code. These two code bases have drifted apart quite a bit because of the difficulty of translating our out-of-kernel changes into the in-kernel driver which uses completely different symbolic register constants. Can you explain this in a little bit more details? what's the source of the need to use two different sets of symbolic register constants? When our cxgb4 driver was first submitted for inclusion in kernel.org someone objected to the format of our symbolic register constants and forced us to change them. Unfortunately these constants are generated directly from our hardware design and we can’t change them internally — it would significantly increase development/debugging time with our hardware team if we had to constantly help the hardware team member translate back and forth between the confusingly similar but different names. Additionally, though I know that this isn’t a concern of kernel.org, every other OS driver for our adapters use the hardware-derived symbolic register constants and our software team internally often work on several different OS Drivers as we work out better ways to do various things. All of this means that our in-house/out-of-kernel driver uses the hardware-derived symbolic constants and every time we need to push a change into kernel.org we need to go through a very careful translation of the symbolic register constants. Casey -- 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
On Mar 5, 2014, at 11:52 AM, Or Gerlitz or.gerl...@gmail.com wrote: On Wed, Mar 5, 2014 at 9:46 PM, Casey Leedom lee...@chelsio.com wrote: On Mar 5, 2014, at 11:39 AM, Or Gerlitz or.gerl...@gmail.com wrote: On Wed, Mar 5, 2014 at 9:15 PM, Casey Leedom lee...@chelsio.com wrote: Yes, thanks mightily for your help and advice and sorry for the size of the updates. Hari has taken on the very difficult task of synchronizing our out-of-kernel development branch with the in-kernel code. These two code bases have drifted apart quite a bit because of the difficulty of translating our out-of-kernel changes into the in-kernel driver which uses completely different symbolic register constants. Can you explain this in a little bit more details? what's the source of the need to use two different sets of symbolic register constants? When our cxgb4 driver was first submitted for inclusion in kernel.org someone objected to the format of our symbolic register constants and forced us to change them. are you referring to constants defined in drivers/net/ethernet/chelsio/cxgb4/t4_hw.h or other/more headers? t4_regs.h. Strangely, when we submitted the driver, the very similar symbolic constant formats in t4_msg.h and t4fw_api.h weren’t targeted; just the ones in t4_regs.h. Casey Unfortunately these constants are generated directly from our hardware design and we can't change them internally -- it would significantly increase development/debugging time with our hardware team if we had to constantly help the hardware team member translate back and forth between the confusingly similar but different names. Additionally, though I know that this isn't a concern of kernel.org, every other OS driver for our adapters use the hardware-derived symbolic register constants and our software team internally often work on several different OS Drivers as we work out better ways to do various things. All of this means that our in-house/out-of-kernel driver uses the hardware-derived symbolic constants and every time we need to push a change into kernel.org we need to go through a very careful translation of the symbolic register constants. -- 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
On Mar 5, 2014, at 11:59 AM, Casey Leedom lee...@chelsio.com wrote: On Mar 5, 2014, at 11:52 AM, Or Gerlitz or.gerl...@gmail.com wrote: On Wed, Mar 5, 2014 at 9:46 PM, Casey Leedom lee...@chelsio.com wrote: are you referring to constants defined in drivers/net/ethernet/chelsio/cxgb4/t4_hw.h or other/more headers? t4_regs.h. Strangely, when we submitted the driver, the very similar symbolic constant formats in t4_msg.h and t4fw_api.h weren’t targeted; just the ones in t4_regs.h. By the way, please don’t take this as in any way advocating that the symbolic constants in t4_msg.h and t4fw_api.h should also be changed in a way which is incompatible with out out-of-kernel development tree — our lives are hard enough already with the changes symbolic constants in t4_regs.h! :-) Casey-- 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. Sure, thanks for the suggestion. I will just re-post the revert patch on cxgb4 now, part of this series, which is causing regression. And, I will split the rest of patch-series into 8-10 patches and re-submit. I think you should keep this series as-is since folks have been reviewing it as such. Then going forward, we need to submit smaller sets more frequently... Steve. -- 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: [PATCHv3 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4
On Tue, Mar 04, 2014 at 13:22:26 -0500, David Miller wrote: 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. Sure, thanks for the suggestion. I will just re-post the revert patch on cxgb4 now, part of this series, which is causing regression. And, I will split the rest of patch-series into 8-10 patches and re-submit. Thanks for the review comments! -Hari. -- 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
