> Stop right here. If you didn't compile IPDIVERT in the kernel,
> the hooks aren't in the tcp/ip stack and you're screwed.
>
> Figuring out a way to fix this is on my TODO list, though I don't
> have any ideas that don't cost a performance hit for non-DIVERT
> users.
The LEASE stuff has a similar problem, but it eats the overhead
anyway, but screws up a number of details in a couple of places,
making it pretty useless to load NFS as a module, at least for
serving.
There are really several ways to do this:
o Jump table with fixup on first call
- This is the least overhead, since each caller is
fixed up once; the bad news is: no unload.
o Another way is to do what the NFS LEASE code does;
this adds a pointer dereference and compare to zero
with jump
- This is more overhead, as you say; the real pain
here is the jump, which wouldn't be necessary, if
it were possible to tell the compiler "I expect
this compare to succeed most of the time" or "I
expect this compare to fail most of the time"
using a "#pragma"; if you could do that, the
compiler could change branch order generation by
tacking a hint onto the quad tree, and reordering
(or not reordering) it. You can get the same
effect by placing the default path inside the
if test, but then you get a branch instruction,
which is not much better.
o A sneaky way to do this is to put the diversion into
the failure path. This makes divert very expensive,
comparatively (in terms of code path), and adds some
constraints to how it must be used, but makes it so
that you only ever divert packets you would otherwise
throw away
- That said, there are server things in the IPFW code
that could be diked out as "more useless than divert",
forceful rejection being one of them, since everyone
who is a bad guy ignores it anyway, so the argument
would be "what's important?", since everyone's choice
for success and failure code path would be different.
- On the other hand, if it's considered so heavy that
it already has #ifdef's for it, the divert code is
a good candidate for failure code path.
My personal vote would be fore LEASE, if the reason is that the
code is large, not because it is slow, and failure path, if it's
because the code is slow, not because it is large.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
