Network stack cloning / virtualization patches
zec at tel.fer.hr
Mon Jun 2 14:59:12 PDT 2003
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.
More information about the freebsd-hackers