Date: Mon, 02 Jun 2003 23:58:25 +0200 From: Marko Zec <zec@tel.fer.hr> To: Sean Chittenden <sean@chittenden.org> Cc: Julian Elischer <julian@elischer.org> Subject: Re: Network stack cloning / virtualization patches Message-ID: <3EDBC881.C99CB47D@tel.fer.hr> References: <20030530133302.A48390@FreeBSD.org> <20030602200158.GH65470@perrin.int.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Chittenden wrote: > > I have been running tests between two machines with this patch > > installed. There is a "per packet" overhead increase of about 1%. > > there is no overhead increase in the per-byte overhead.. in ther > > words, sending 1 byte packets gets about a 1% decrease in throughput > > but sending 8k chunks has almost no overhead increase.. > > > > Both my machines end up maxing out the 100Mb ethernet between them > > before they see any speed difference at high packet sizes. > > 1% per packet seems a bit high... where is the overhead coming from? > Seems as though there should be less overhead and that lookup of the > necessary components for each vimage could be found with a hash... I > looked through the patch and couldn't see any places that screamed > optimization. Is the overhead really just from copying the data of > the vimage around? There are two major possible causes for overhead increase. First, each IP protocol related tunable variable and most of the global symbols involved in network processing have been virtualized. This means that instead of being accessed directly, the symbols have to be dereferenced inside a struct vimage. The described additional level of abstraction means that more clock cycles will be spent on each access to any of those symbols, which happens rather often in case of relatively complex TCP processing. And second, many kernel functions have been extended with an additional argument, typically a pointer to a struct vimage, so passing and fetching the extended argument lists has certainly also contributed to the slight decrease in TCP performance. However, a couple of percents in overhead increase that can be observed only in worst case loopback tests do not present a problem in any real-life scenario. On the other hand, I do not follow what you are aiming at with hash lookups? Also, there's no special copying of data to / from vimages as you are suggesting, besides the described dereferencing the virtualized symbols within the struct vimage. > Julian, am I safe in assuming that you have an interest in this work? > If not, I may setup a p4 branch to work with and to merge these bits > into -CURRENT if no one else is interested. -sc I would be really honored to see the cloning code merged in -CURRENT one day. However, at the moment I'm strongly opposed to such a proposal, since the code is simply not mature enough. As explained in one of the previous notes, the vimage should be first restructured as a modular resource container facility, vs. the current monolithic implementation. Many people have also proposed the API to be reengineered. Further, no protocol except IPv4 (excluding IPSEC) has been virtualized at the moment, etc. Forcing such a partial solution into the official tree would beyond any doubt create a terrible mess, a huge amount of breakage, a lot of unnecessary fights and debates, but most of all it would make it more difficult to do the virtualization properly once the original patch becomes mature enough. Cheers, Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EDBC881.C99CB47D>