Date: Wed, 2 Nov 2005 22:40:55 -0500 From: "David S. Madole" <david@madole.net> To: "kamal kc" <kamal_ckk@yahoo.com>, "freebsd" <freebsd-net@freebsd.org> Subject: Re: allocating 14KB memory per packet compression/decompression resultsin vm_fault Message-ID: <024f01c5e028$66182820$c3e7a8c0@david> References: <20051103023936.63209.qmail@web35704.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "kamal kc" <kamal_ckk@yahoo.com> > > i am trying to compress/decompress ip packets. > for this i have implemented the adaptive lzw compression. > i put the code in the ip_output.c and do my compression/decompression > just before the if_output() function call so that i won't interfere > with > the ip processing of the kernel. I don't have an answer for you, but I'm curious what you are doing that makes it better than the IPComp compression that is already available in IPSEC? If it's just LZW versus LZ77, have you considered merely extending the existing IPSEC implementation with just the additional protocol option? It seems like it would be better than reinventing the wheel -- you would have the advantage of the existing security policy framework to select what and how to encrypt as well as a working example of how to do it in the LZ77 code that's already there. If you do need to do something truly one-off and unique, I have found that writing it as a userland process and hanging it off a divert socket is an easy way to manipulate IP packets. It's not as efficient as putting it in the kernel, but it's a heck of a lot easier to write and debug and it's independent of kernel versions and other changes. You also get the benefit of being able to use ipfw rules to determine what gets processed rather than rolling your own configuration mechanism. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?024f01c5e028$66182820$c3e7a8c0>