Date: Tue, 25 Jan 2000 23:38:09 -0700 From: Brett Glass <brett@lariat.org> To: Don Lewis <Don.Lewis@tsc.tdk.com>, Matthew Dillon <dillon@apollo.backplane.com> Cc: security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Merged patches Message-ID: <4.2.2.20000125232750.04074b50@localhost> In-Reply-To: <200001260605.WAA28922@salsa.gv.tsc.tdk.com> References: <4.2.2.20000125113518.01a59100@localhost> <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> <4.2.2.20000125113518.01a59100@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:05 PM 1/25/2000 , Don Lewis wrote:
>A switch based on the TCP flags would be a very unnatural implementation.
>For instance, most of the processing done on a packet received on an
>established connection is the same whether the FIN bit is set or not.
A switch statement can allow the same group of statements to be executed
for more than one combination of the flags.
>If the switch expression was based on the flags, then a large part of
>the code would be duplicated between these two cases.
It is also possible to "fall through" from one case to another. This makes
the switch statement a very powerful tool for this sort of situation. It
is also possible to call a common subroutine. The overhead of a fixed
subroutine call is often less than that of a conditional branch on
today's CPUs.
> Also, the code
>may do some processing on the segment, clear the SYN and/or FIN bits,
>and then continue.
I'd think it would be unusual -- perhaps bad form -- to alter the flags,
as it would make the code harder to follow. In what situation(s) would
you do this?
In any event, one cannot always subsume ALL of the conditional jumps
in a routine into a single switch. But one usually CAN reduce the
number greatly. Matt seems skeptical, and I am sure that no one will
want to change the code much before the freeze. But I'd like to take
a shot at rewriting the code, using some switches instead of if
statements, after the freeze. I think that it will have several major
benefits: it'll make the code faster; it'll make it easier to read;
and it will make it glaringly obvious if a case that should be considered
has been missed.
>A implementation that used a switch based on the socket state would
>be somewhat more natural, but this is still not an exact fit. As
>a matter of fact, if you look at the implemention, this is pretty
>much what a lot of it does.
>
> switch (tp->t_state) {
> case TCPS_LISTEN: {
> ...
Yes, it is true that switching on the socket state would be handy.
The real power of the switch statement, however, shows when it is
used to consider combinations of flags in parallel, as with the
TCP option flags. Again, I see some skepticism here about whether
it will really make the code faster or more readable, so as soon
as 4.0 is frozen I'll generate some code that shows what I have in
mind.
--Brett
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000125232750.04074b50>