On Tue, Jul 10, 2007 at 01:38:25PM -0700, [EMAIL PROTECTED] wrote: > >It took a while to get it right, as well as to get the test environment (some > >will-remain-undocumented in.iked changes in usr/closed) right. > > > > > > I'm not sure I understand this. > > Are you saying that there have been changes made to in.iked that won't > be documented, leaving this as an undocumented feature?
I am. The reason is because most people will want a "4500 *and* other ports" interface for in.iked, and that requires a ton more work. The undocumented feature is "4500 *or* one other port". We've seen that test tools can be integrated into our source (even closed source, as in.iked is). This undocumented feature is a test tool. > >I now have a new public webrev: > > > > http://cr.opensolaris.org/~danmcd/detangle/ > > > >... > > > > 2.) UDP and IP performance folks --> am I slowing any UDP hotpaths > > down? I was looking at using the conn_t's input function pointer > > to reroute NAT-T sockets, but it seemed harder than it needed to > > be. Maybe I'm missing something, but some of the options > > processing happens in ip_fanout_udp_conn() or ip_udp_check() and > > it seems I can't really do the zero-SPI stripping after those > > functions. > > > > > > Well, in udp fanout, there's a new if() with a double pointer deref.... Ahhh yes. In a *perfect* world, I'd have been able to rewrite connp->conn_recv() to point to an SPI-checking version of udp_input(), but there's stuff that's done in IP itself BEFORE conn_recv() gets called. Such stuff includes all sorts of other receive-side options (recvif, recvslla, recvpktinfo) that need to percolate up as well. I don't want to do those until I've done appropriate zero-SPI stripping or demux to ESP. Also, that fanout with the double-deref is not a UDP fast-path function. Fast path is: ip_input() ip_udp_input() (returns) slow-path is ip_input() ip_udp_input() (has options, fragmentation, etc.) ip_fanout_udp() (returns) But we still double-deref, just not all at once... see ip_udp_check() for the fast-path version of what's in ip_fanout_udp(). We have a new local that caches conn_udp. One thing we *could* do is store the UDP_NAT_T_ENDPOINT bit in the conn_t itself rather than udp_t. Given that udp_t and conn_t are allocated together, however, I didn't think the double-deref would cause a lot of cache problems, and it may even pre-load things for UDP processing itself. > ip.c - 17933 - I prefer long winded if() clauses over clever tricks like > this. Easier to read, easier to debug. Let the compiler worry about > optimisations like this. That's the rub --> compilers don't do optimizations like this. Read after the separator line for details, but for now, I'm not going to change this. I can document it better, but I won't change it. ===================== (Cut up to and including here.) ===================== Compilers most likely can convert: if ((long-boolean1 && !long-boolean2) || (!long-boolean1 && long-boolean2)) into a = eval(long-boolean1); b = eval(long-boolean2); if ((a && !b) || (!a && b)) but they won't EVER reduce to XOR, at least not with the options or compilers default OpenSolaris uses. Here's a toy program to try with your favorite compiler and options. Use the PRE_CSE (manual common-subexpression-elimination) and USE_XOR (obvious) definitions with -D<foo> to see how the output changes: ===================== (Cut up to and including here.) ===================== #include <sys/types.h> #include <ctype.h> #include <stdlib.h> #include <stdio.h> int main(int argc, char *argv[]) { #ifdef PRE_CSE boolean_t a, b; #endif if (argc < 2) { printf("usage: %s [arg1] <arg2...n>\n", argv[0]); return (1); } #ifdef PRE_CSE a = (argc > 2); b = (isdigit(*argv[1])); #else #define a (argc > 2) #define b (isdigit(*argv[1])) #endif #ifdef USE_XOR if (a ^ b) #else if ((a && !b) || (!a && b)) #endif printf( "Aha! (more-than-one arg) XOR (arg(1) is a number (%d)).\n", atoi(argv[1])); return (0); } ===================== (Cut up to and including here.) ===================== BTW, the nature of isdigit() allows some other optimizations, but the general concept remains the same. I wonder if one of us should file a compiler RFE? There is no '^^' operator in C, but if the compiler can extract common-subexpressions, it *should* be able to reduce ((a && !b) || (!a && b)) into something resembling (a ^^ b) if C had such an operator. Dan _______________________________________________ networking-discuss mailing list [email protected]
