[Top] [All Lists]

Re: [RFC] cleaning up struct sock

To: Steve@xxxxxxxxxxx, steve@xxxxxxxxxxxxxx
Subject: Re: [RFC] cleaning up struct sock
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 11 Dec 2001 03:47:55 -0800 (PST)
Cc: acme@xxxxxxxxxxxxxxxx, jschlst@xxxxxxxxx, ncorbic@xxxxxxxxxxx, eis@xxxxxxxxxxxxx, dag@xxxxxxxxxxx, torvalds@xxxxxxxxxxxxx, marcelo@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200112111114.LAA29992@xxxxxxxxxxxxxx>
References: <20011210.231826.55509210.davem@xxxxxxxxxx> <200112111114.LAA29992@xxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
   From: Steven Whitehouse <steve@xxxxxxxxxxxxxx>
   Date: Tue, 11 Dec 2001 11:14:39 +0000 (GMT)

   > 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.
   We do have to allocate an inode as well though (at least in the normal
   case) and with the new (if I've understood the conclusions of the
   discussions on inode allocation) scheme this would give us a single
   allocation which would be sizeof(struct inode) + sizeof(struct socket)
   in a slab cache private to sockfs.
Indeed, you are right.  But I don't know about the inode+socket idea.

   I wonder if we could allocate a combined object along the lines of the
     a) struct inode
     b) struct socket
     c) struct sock (minus per protocol areas)
     d) struct my_protocol (whatever the socket actually is)
     e) anything else required
   all in one go.

The reference counting would be a pain in the neck, I think.

If we can somehow "genericize" the "inode + extra stuff" into
some abstraction, sure maybe.

I don't know, it could work.

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