Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]

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 <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]