Re: [PATCHv6 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4
[[Sorry, the first effort at this reply fell afoul of netdev’s HTML email filter and my Mail Agent’s default modes. — Casey]] On Mar 12, 2014, at 12:51 PM, David Miller da...@davemloft.net wrote: This is becomming beyond tiring. Im really sorry for how much work this has turned into David. Hari is trying to do the right thing but it’s an insanely large patch set. A while back someone recommended backing off and restarting with a series of much smaller patch sets. I think the decision at that time was that too much time had gone into this patch set so Hari should proceed with the effort. Should we revisit that decision and ask Hari to submit a series of much smaller patch sets (one at a time obviously)? 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
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 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: [PATCH net-next 05/22] cxgb4: Add T5 write combining support
On 03/13/13 08:43, David Laight wrote: From my recollection of the x86 architecture, the memory barriers are hardly ever needed, certainly not in the places where, for example a ppc needs them. I'd actually suspect that the normal wmb() for x86 should be a nop. About the only place where any on the fence instructions are needed are in relation to write combining accesses. In particular I don't believe they are ever needed to synchronise uncached accesses with each other, or with cached accesses (which are snooped). David The question at hand is how should we indicate that we're finished with a Write Combined set of stores in an architecturally neutral manner? Is wmb() a good approach? Vipul has noted that the iWarp code uses a new wc_wmb() for this purpose which seems to be the same _currently_ as wmb() for all current platforms. I presume that the iWarp folks pick a new name to offer themselves some cover in the future. And yes, the code sequence that was accidentally included in Vipul's previous patches should never have been submitted for inclusion in kernel.org. It got missed in our internal reviews and I apologize for that. 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
