From owner-freebsd-net@FreeBSD.ORG Tue Mar 2 12:49:31 2004 Return-Path: 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 6FEAE16A4CE; Tue, 2 Mar 2004 12:49:31 -0800 (PST) Received: from mail.tel.fer.hr (zg04-080.dialin.iskon.hr [213.191.137.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26A2043D45; Tue, 2 Mar 2004 12:49:30 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: from marko-tp.katoda.net (marko@dhcp11.katoda.net [192.168.200.111]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id i22KnGuP004242; Tue, 2 Mar 2004 21:49:17 +0100 (CET) (envelope-from zec@tel.fer.hr) From: Marko Zec To: Julian Elischer , James Read Date: Tue, 2 Mar 2004 21:48:37 +0100 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403022148.38002.zec@tel.fer.hr> cc: "Bjoern A. Zeeb" cc: freebsd-current@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Was: My planned work on networking stack (vimage) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 20:49:31 -0000 On Tuesday 02 March 2004 21:01, Julian Elischer wrote: > The major problem with 'vimage' is that all statics are moved to a > large structure so that they can be duplicated... > e.g. The root of the interface list gets moved there so that each > vimage has its own list of interfaces. > > > This is ok for statically compiled modules, but what can you do for > adding new modules.. either statically of dynamically.. > > You end up having to have each module have it's own structure and > each vimage has to have its own list or array of such structures.. > Hi, Julian! True, this can also become an issue. However, the question is how many modules in real-life do require per network stack symbols/structures. For example, the original vimage patch already included the necessary hooks and reserved the appropriate fields for ipfw or dummynet to be loaded / unloaded dynamically with no major problems. On the other hand, no device driver should be affected by the virtualization, and shouldn't require any network-stack specific handling. And IMO the device drivers are those which are most commonly implemented as loadable modules. Cheers, Marko > > so to use the example above, > ifp = TAILQ_HEAD(ifhead) /* I forget the exact names */ > > becomes something like: > > ifp = TAILQ_HEAD((struct > netbase_statics*)(p->vimage[netbase_index])->ifhead); > > Where netbase_index is a global set when the networking base module > is loaded or linked in, (no idea by who), and the 'vimage' becomes an > array of void * pointers, each pointing to a different structure aof > variables that were once static, each structure being variables > related to a different module. > > > This could be done but it starts to look a lot like the TLS (Thread > Local Storage) stuff. > And it would pretty definitly have a performance impact. >