> 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

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

Reply via email to