From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 03:41:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BCFE16A41F for ; Thu, 3 Nov 2005 03:41:03 +0000 (GMT) (envelope-from david@madole.net) Received: from a.omd3.com (a.omd3.com [69.90.174.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1482443D46 for ; Thu, 3 Nov 2005 03:41:02 +0000 (GMT) (envelope-from david@madole.net) Received: from dhcp-66-212-201-164.myeastern.com ([66.212.201.164] helo=david) by a.omd3.com with esmtpa (Exim 4.54) id 1EXVyH-00014g-Qw; Wed, 02 Nov 2005 22:41:02 -0500 Message-ID: <024f01c5e028$66182820$c3e7a8c0@david> From: "David S. Madole" To: "kamal kc" , "freebsd" References: <20051103023936.63209.qmail@web35704.mail.mud.yahoo.com> Date: Wed, 2 Nov 2005 22:40:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Cc: Subject: Re: allocating 14KB memory per packet compression/decompression resultsin vm_fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 03:41:03 -0000 From: "kamal kc" > > 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