Stephen C. Tweedie wrote:
> int accept (int oldfd, struct sockaddr *, int *addrlen,
> int newfd, pid_t sigpid, unsigned int clone_flags)
Some mechanism for creating new socket fds is required, and it will be
used because load does come and go. We would like to adapt the number
of sockets retained by the application to fit the load.
It's probably worth allowing new_fd == -1. That means to search for a
free fd after all. You could also supply a known unused new_fd value,
and it would do the same as dup2().
But that doesn't allow for inheriting properties.
If new socket creation is not done often, that doesn't matter. You can
use fcntl() to set properties on new sockets, and poll() to handle the
races. But if sockets are created often then you want some way to copy
properties from another socket.
One way is SOCKCLONE_COPY (copy newfd's properties but pick a different,
free fd value); another is to inherit properties from the listening
socket itself in the new_fd == -1 case. Perhaps the latter behaviour
could be specified in general with an orthogonal flag: SOCKCLONE_PARENT.
> clone_flags will be a bitmap indicating what properties of the original
> socket we want to copy to the new one, including the obvious ones:
>
> SOCKCLONE_ASYNC
> SOCKCLONE_NONBLOCK
> SOCKCLONE_CORK
> SOCKCLONE_LINGER
> SOCKCLONE_RBUF
> SOCKCLONE_WBUF
> SOCKCLONE_SIG
> plus a possible new function,
> SOCKCLONE_POLLNEW
> to place a POLLNEW marker into the siginfo stream.
I think that is far too many. The TCP options aren't required.
Consider, what are the property values when you don't set a clone bit?
You don't want the defaults. Suppose you're serving HTTP. Then you
want new sockets to have the CORK option set, but sockets that are being
recycled will have that option cleared (otherwise the data would never
get sent).
So you want to unconditionally set CORK. One way is to have that set
for the listening socket, where it has no effect, and inherit from that.
Another is a special SOCKCLONE_SET_CORK flag, but it's looking pretty
ugly now.
Another way is to just do the setsockopt syscall, bearing in mind it has
no impact on scalability, just raw performance. General policy is not
to merge syscalls together, so perhaps this should be no exception.
With this in mind, perhaps flags such as SOCKCLONE_CORK and
SOCKCLONE_LINGER are inappropriate.
> This shouldn't need a new method in the sock ops, with the possible
> exception of dealing with protocol-specific inheritance of things like
> the tcp cork settings.
How about simply making TCP's accept mechanism _always_ inherit the
properties from the listening socket, even for accept()? I don't think
there is any legitimate use for a listening socket having different TCP
options to a non-listening socket, so I don't expect any applications do
that or would be affected.
Then you don't need a new method in the socket ops, and even old style
accept() is more scalable.
Comments from the network people, please...
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:30 EST