From owner-freebsd-arch Wed Nov 27 9:14:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF12137B404 for ; Wed, 27 Nov 2002 09:14:22 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with SMTP id ED3A343EBE for ; Wed, 27 Nov 2002 09:14:16 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: (qmail 28053 invoked from network); 27 Nov 2002 18:14:14 +0100 Received: from zg06-044.dialin.iskon.hr (HELO tel.fer.hr) (213.191.148.45) by mail.iskon.hr with SMTP; 27 Nov 2002 18:14:14 +0100 Message-ID: <3DE4FD66.78DE9AEB@tel.fer.hr> Date: Wed, 27 Nov 2002 18:14:14 +0100 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Julian Elischer , "M. Warner Losh" , phk@critter.freebsd.dk, rwatson@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: ABIs and 5.x branch: freeze kernel module ABI at 5.0 or 5.1? References: <20021127.002657.21921523.imp@bsdimp.com> <20021126234344.A59511@xorpc.icir.org> <3DE4EB22.39D9BD07@tel.fer.hr> <20021127081054.A76965@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > On Wed, Nov 27, 2002 at 04:56:18PM +0100, Marko Zec wrote: > ... > > > mbufs. ifnet's can be easily extended in much the same way used by > > > the bridging code (by using the if_index to point into external > > > arrays containing specific extensions); processes/threads/kseg have > > > the extra pointer/room for custom schedulers... I think the > > > usual suspects are all covered. > > > > This concepts are unfortunately not applicable in case of virtualization / > > cloning of the entire network stack. As each network stack instance has its > > own set of arrays a'la ifindex2ifnet[], the if_index often has the same value > > i don't follow. Why can't you think of the if_index as a unique identifier > for the actual device and put the extra pointer in extra_pointer[if_index] ? > This way you can also have per-virtual-image instances of whatever > extra info you need. if_index is not only used for accessing ifindex2ifnet[], but some other arrays as well, such as ifnet_addrs[] or ipx_ifaddr[]. If we want to have fully independent network stacks with overlapping addressing schemes, the simplest and cleanest approach is a clear separation of all those arrays containing any type of addressing information. Otherwise, many parts of the code traversing through those arrays would have to be extended with an additional logic, which in my opinion would not make these code chunks more difficult to comprehend, but would also decrease their efficiency as well. > Same for struct proc (we used a few spare bytes in > -stable' struct proc exactly in this way, storing an equivalent of > if_index, and going to an external structure through it to access > extension information for our proportional share scheduler). > There are surely minor performance issues with this (you have > to go through a base_ptr+index whenever you access the extra info > instead of using a direct pointer), but in many cases this disappears > in the noise. That's exactly what I've done in the original 4.7-R patch. However, it is clear that using a dedicated pointer directly in struct proc instead of having an index to external array of pointers would be not only more efficient solution, but also probably a more readable one. I just think right now (before 5.0 is released) we have a nice opportunity to introduce some spare pointers for such or similar purposes, without making significant sacrifices or introducing a whole bunch of new problems at the same time. Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message