[Top] [All Lists]

Re: [RFC] cleaning up struct sock

To: acme@xxxxxxxxxxxxxxxx
Subject: Re: [RFC] cleaning up struct sock
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Mon, 10 Dec 2001 23:18:26 -0800 (PST)
Cc: SteveW@xxxxxxx, jschlst@xxxxxxxxx, ncorbic@xxxxxxxxxxx, eis@xxxxxxxxxxxxx, dag@xxxxxxxxxxx, torvalds@xxxxxxxxxxxxx, marcelo@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20011210230810.C896@xxxxxxxxxxxxxxxx>
References: <20011210230810.C896@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
   From: Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx>
   Date: Mon, 10 Dec 2001 23:08:10 -0200
   David, if you don't like it, I'll happily switch to the big fat
   union idea, but I think that this is more clean and will avoid us
   having to patch sock.h every time a new net stack is added to the

I'm a little concerned about having to allocate two objects instead of

These things aren't like inodes.  Inodes are cached and lookup
read-multiple objects, whereas sockets are throw-away and recycled
objects.  Inode allocation performance therefore isn't that critical,
but socket allocation performance is.

Then we go back to the old problem of protocols that can be used to
embed IP and thus having to keep track of parallel state for multiple
protocols.  I think your changes did not compromise that for what
we currently support though.

I still need to think about this some more....

You know, actually, the protocols are the ones which call sk_alloc().
So we could just extend sk_alloc() to take a kmem_cache_t argument.
TCP could thus make a kmem_cache_t which is sizeof(struct sock)
+ sizeof(struct tcp_opt) and then set the TP_INFO pointer to "(sk +

Oh yes, another overhead is all the extra dereferencing.  To fight
that we could make a macro that knows the above layout:

#define TCP_PINFO(SK)   ((struct tcp_opt *)((SK) + 1))

So I guess we could do things your way without any of the potential
performance problems.

It is going to be a while before I can apply something like this, I
would like to help Jens+Linus get the new block stuff in shape first.
This would obviously be a 2.5.x change too.

<Prev in Thread] Current Thread [Next in Thread>