Date: Wed, 25 Oct 2000 22:12:24 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: billf@chimesnet.com (Bill Fumerola) Cc: leif@neland.dk (Leif Neland), freebsd-current@FreeBSD.ORG Subject: Re: divert as module? Message-ID: <200010252212.PAA06384@usr01.primenet.com> In-Reply-To: <20001025125212.M37870@jade.chc-chimes.com> from "Bill Fumerola" at Oct 25, 2000 12:52:12 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200010252212.PAA06384>