Date: Fri, 15 May 1998 22:41:33 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Julian Elischer <julian@whistle.com> Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf param.c src/sys/kern uipc_domain.c uipc_proto.c uipc_socket.c uipc_socket2.c uipc_usrreq.c src/sys/netinet in_pcb.c in_pcb.h ip_divert.c raw_ip.c tcp_subr.c tcp_var.h udp_usrreq.c udp_var.h Message-ID: <199805160241.WAA04085@khavrinen.lcs.mit.edu> In-Reply-To: <355CC35D.2F1CF0FB@whistle.com> References: <199805152011.NAA12272@freefall.freebsd.org> <199805152020.QAA02956@khavrinen.lcs.mit.edu> <355CC35D.2F1CF0FB@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 15 May 1998 15:36:13 -0700, Julian Elischer <julian@whistle.com> said:
[I wrote:]
>> My preference would have been to make the socket structures simply be
>> a part of the PCB structures, thus allocating everything in one swell
>> foop. However, I was not able to convince myself that one or the
>> other could not exist ``bare'', so I took the easy way out.
> thanks
You're not welcome :-( .
> I'm playing with pcb's here without sockets..
I don't believe that such a situation is correct (at least with
respect to the architecture of the network code). The only reason I
left things as they were was because I didn't have the time to trace
through the TCP state machine to ensure that sofree() could never
actually succeed until the connection was out of TIME_WAIT. I believe
that that is how it is supposed to be, as differentiated from how it
may or may not actually be.
In any case, you would still be free to allocate PCBs all you want;
you just wouldn't be able to run them through the usual code path, and
you could get hit with an extra 160 bytes per allocation (of which 72
comes from the socket buffers, lose lose).
One of the things I hope to achive by this, besides reducing the
overhead of creating a socket, is to eliminate the so_pcb, inp_socket,
inp_ppcb type references by replacing them with pointer arithmetic.
For example:
#define sotoinpcb(so) (struct inpcb *)(so)
#define inptosocket(inp) (struct socket *)(inp)
#define inptotcpcb(inp) (struct tcpcb *)(inp)
/* open-coded for clarity */
struct tcpcb {
union {
struct inpcb {
union {
struct socket inpu_so;
char align[ALIGN(sizeof(struct socket))];
} inp_inpu;
#define inp_so inp_inpu.inpu_so
...
} tu_inp;
char align[ALIGN(sizeof(struct inpcb))];
} tp_tu;
#define tp_inp tp_tu.tu_inp
...
};
This might be clearer if written in C++ style:
class tcpcb : public inpcb {
// alignment
// ...
};
class inpcb : public socket {
// alignment
// ...
};
Now, in the long run, `struct inpcb' as such wants to go away
entirely, but it will be a long time before we are able to take such a
step.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805160241.WAA04085>