Date: Thu, 12 Mar 2009 13:44:46 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Vadim Goncharov <vadim_nuclight@mail.ru> Cc: freebsd-arch@freebsd.org Subject: Re: spliting kernel ipfw source ? (also involves sctp) Message-ID: <20090312124446.GB28491@onelab2.iet.unipi.it> In-Reply-To: <slrngrhs22.iuq.vadim_nuclight@server.filona.x88.info> References: <20090301153010.GA58942@onelab2.iet.unipi.it> <49AAFD92.105@elischer.org> <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> <alpine.BSF.2.00.0903021827400.11098@fledge.watson.org> <20090302190157.GA33704@onelab2.iet.unipi.it> <slrngr26ef.r98.vadim_nuclight@server.filona.x88.info> <20090306161028.GA12322@onelab2.iet.unipi.it> <slrngrhs22.iuq.vadim_nuclight@server.filona.x88.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 12, 2009 at 11:21:38AM +0000, Vadim Goncharov wrote: > Hi Luigi Rizzo! ... > > In practical terms, ip_fw.h might lose the definition of > > struct ip_fw_args, or the prototypes for the various kernel > > functions. The #ifdef _KERNEL part of ip_dummynet.h should > > also go to some other file. > > > If you want to contact me, on the list or offline, to discuss what > > you want to do or what kind of 'modules' (kernel or userland ?) are > > you thinking about, i'd be more than happy to help. > > I do not know whether this will be polite to discuss in details while > Foundation has not yet announced my work :-/ I hope they'll do it in a week I see no reason to keep things secret. In fact, I'd try to be as open as possible as there is plenty of people on this list with with a lot of experience on the various issues at hand, and could give you valuable feedback. > or so... I could say that at least dynamic rules and userland API/ABI will > go under serious incompatible changes, so any your changing headers is OK, > but what do you want to change inside kernel *.c is interesting to me. First of all I want to split the files because ip_fw.2 is currently too large to be effectively maintained. There are more things that should be addressed, after proper performance assessment, e.g replacing the huge switch with a table of function pointers, fixing the way information is passed up in the "ipfw show" and "pipe show" commands, replacing the custom hash table with something already in the kernel, and perhaps a better hash function. Even more work (but this is not something I plan to do) involves the locking: there is contention on the rule counters (which I am not sure if/how is handled now) and contention on the dynamic rules, which possibly might be reduced by locking on the individual buckets. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090312124446.GB28491>