Date: Wed, 27 Nov 2002 18:14:14 +0100 From: Marko Zec <zec@tel.fer.hr> To: Luigi Rizzo <rizzo@icir.org> 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: <3DE4FD66.78DE9AEB@tel.fer.hr> 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> <20021127081054.A76965@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE4FD66.78DE9AEB>