On 12/09/2015 01:44 PM, Christoph Hellwig wrote: > On Wed, Dec 09, 2015 at 01:13:29AM +0200, Or Gerlitz wrote: >> >> Christoph patch is here indeed, it does two things >> >> 1. remove all the ULP device attr alloc, device query, attr free hassle >> 2. adds tons of new fields to struct ib_device >> >> I think it just goes too much and needlessly adds tons of these new >> fields directly to struct ib_device where we can have them all well >> scoped into ib_device_attr member or pointer from struct ib_device > > What's the benefit of that?
Organization. Let's be fair, the totally flat namespace you are preferring is the equivalent of a teenager that is completely incapable of picking thier dirty laundry up off the floor. It is sloppy, disorganized, often full of old cruft that you don't know if you can get rid of or not, often so disorganized you might have three similarly named items that you can't figure out which one should be used in which circumstances, etc. The downside of a more organized approach is often longer/more complex variable names. It also means that if you want to micro-optimize for which variables are in the hot path and you need one and only one of the variables from the attr struct, then you either have to make a copy somewhere else that is in a frequently hot cache line (along with making sure the copy and the original stay in sync) or you have to take it out of the attr struct, or other bad things. > And looking at the existing members of > struct ib_device what determines if it goes straight into the device > or the attribute? Organization. What goes where depends on what makes sense according to the organization you are doing. > There is a reason why we don't do this weird > attr split in other Linux subsystems, and making IB follow this pattern > makes everyone feel right at home instead of wondering about the > weird attribute. Being organized is not "weird". Let's not wax poetic about sloppy, disorganized structures. Let's be honest about what they are so we don't feel like we need to take a shower every time we talk about them to purge us of the sins of our lies. That said, though, the kernel frequently has hot spots that require we have the freedom to rearrange structures to suit memory placement constraints. It's really for that reason more than anything else that we tolerate these horribly disorganized structures with a totally flat namespace. And to be fair, any super high speed core code like the IB code is more susceptible than most to issues of cache line delays and hot path slow downs. For that reason, and *only* that reason, I'm inclined to take your patch. Otherwise, I wouldn't touch it. The rest of the kernel may think a disorganized, flat namespace is fruit punch kool-aid...I happen to prefer things differently. But I'm willing to acquiesce to the needs of a high performance kernel subsystem as appropriate regardless of my personal taste on the issue. -- Doug Ledford <[email protected]> GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
