Date: Wed, 27 Nov 2002 08:10:55 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Marko Zec <zec@tel.fer.hr> Cc: Julian Elischer <julian@elischer.org>, "M. Warner Losh" <imp@bsdimp.com>, 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? Message-ID: <20021127081054.A76965@xorpc.icir.org> In-Reply-To: <3DE4EB22.39D9BD07@tel.fer.hr>; from zec@tel.fer.hr on Wed, Nov 27, 2002 at 04:56:18PM %2B0100 References: <20021127.002657.21921523.imp@bsdimp.com> <Pine.BSF.4.21.0211262328210.57127-100000@InterJet.elischer.org> <20021126234344.A59511@xorpc.icir.org> <3DE4EB22.39D9BD07@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021127081054.A76965>