On Fri, Apr 3, 2015 at 1:31 AM, ira.weiny <ira.we...@intel.com> wrote: > On Thu, Apr 02, 2015 at 05:32:53PM +0300, Or Gerlitz wrote: >> On Wed, Apr 1, 2015 at 12:33 AM, Hefty, Sean <sean.he...@intel.com> wrote: > > [snip]
>> Your claim says more or less "don't touch the good old >> include/rdma/ib_verbs.h from 2.6.12, just add new low-level drivers" >> -- this is very close to claiming that it doesn't make sense to change >> anything in the low areas of the core networking stack or in >> netdevice.h over the years, just add new Ethernet drivers. This does >> not make any sense. > I don't think the question is "if" we should change the core but "how". > Seans point is that the core seems to be in constant flux. Furthermore, > Roland > and others have found enough problems with the core changes in the past that > they are _not_ comfortable applying them without serious review. Ira, examples please for core changes that went in and later turned to be problematic?! I refer to APIs and structural changes that turned to be such (not or to less extent point bugs, which should be avoided too, you know..) > Many of the changes proposed here are completely new and require serious > time to understand. > Most people on this list have limited time and are unable to review every > vendors hardware implementation. What they do care about is how those > changes > affect the core and how those core changes then affect their hardware, other > hardware they use, and the ULPs. This becomes a huge amount of time. You're mixing between vendor's driver code to core changes -- "unable to review every vendors hardware implementation" -- is clear and we didn't ask for that. As for what's involved in merging core API changes - you made good description of what's needed there --- but this is all about the development and evolution of a core stack for domain X (networking, block storage, virtualization, RDMA or you namde it). Such an argument must not be used, since can kill X's stack development and the rdma case, leave us with the 10y old 2.6.12 based verbs header file. > To facilitate this we should be looking for ways to minimize and be very clear > the ramifications of the core changes. In addition, we need to identify where > the core needs to be cleaned up such that future core changes are either 1) > unnecessary or 2) easily reviewable because of their limited impact to other > areas. I am not sure to follow on the core cleanup proposal, but open for suggestions / ideas, please elaborate on this little further. > With all that said, I too must voice my concerns with Rolands lack of > activity. > There have been some good discussions recently on re-architecting the device > feature indicators which were spawned from my OPA MAD changes. > Various alternatives have been submitted and discussed but Roland has not > weighed in on which are acceptable. This makes it difficult to determine what > direction we should take. 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. > Also, recently I found out my repo for the 0-day build was no longer testing > my > branches because Rolands for-next branch was too old. I see today that Roland > has updated to 4.0 rc now. Thank you. I added Sagi, Haggai and Shachar from Mellanox. They are behind few of the major core changes that went in -- Protection/Signature (Sagi), ODP (all), so if you find some concrete example on why/how these changes were not architectured well enough, they will be happy to listen and respond. BTW - the Signature verbs are now on their way to new use case, namely offloading CPU %% used today for CRC and such calculations in Web2/Hadoop applications. Haggai/Shachar are in-charge on the changes for name-spaces to support containers on which Sean isn't responding for few months. -- 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
