|
Hello,
On Tue, 2 Jul 2002, Roberto Nibali wrote:
> Hi Julian,
>
> > I now read the 2.2 patch, it is short enough. One qustion,
> > though: what happens if the real server weight is changed (even
> > to 0) while the conns are above the threshold? Any problems
> > with applying "old" old_weight after autostarting the RS?
>
> This is one point in the TODO :). Yes, I know the problem arises
> when changing weight when (curr->weight == 0). It will activate back
> the server and set the threshold values back to 0. Another problem
> is the one you described. I don't know for the best solution but
> I think I need an old-threshold variable :(.
>
> > May be something have to be done when the RS is edited?
>
> Yes. What do you have in mind?
I'll try to analyze the code tonight or tomorrow, we have
to solve it somehow :)
> > Once Wensong mentioned about modifying the user space
> > structures and separating them. May be such features can
> > use their own setsockopt command to modify the kernel
> > structures without creating problems for the other libipvs
> > users. I.e. we have generic structure for working with the
> > real/virtual servers and other extra structures for additional
> > stuff which again modifies the kernel ones.
>
> Oh, and how would you disable the feature? I mean it would be
> nice to do it with a setsockopt because then the ifdef would
> be gone. But then we have the a test like
The feature is disabled by default because the l_thresh and
u_thresh fields will be always present in the kernel structure
but there will be different user space structures for editing
a RS. Think for it like your patch is applied to the kernel
without any ifdefs but the user space struct is not touched. It
contains only the basic fields every user relies on. There will
be another user space structure again mentioning the
vs, rs and the new threshold fields:
struct edit_rs_thresholds {
cmd; // Always the first field identifying
// what kind of struct follows
vs part
rs part
u_thresh
l_thresh
};
setsockopt uses only one registered value, the variations
are in the cmd value. Sort of this.
The result: the generic user space structures allow the
binaries to work even while new kernels are compiled with new
features that allocate new user space structures. The binaries
not using thresholds will not notice that your patch extended
the kernel RS structure as long as the default values (thresholds
disabled) do not hurt them. Of course, we should think about the
atomicity of editing the RS in so many ways.
> atomic_read(&dest->inactconns) +
> atomic_read(&dest->activeconns)) <=
> dest->l_thresh) && (dest->old_weight > 0)
>
> would introduce some additional CPU cycle burns :).
Not much, we can use something sort of:
if (unlikely(dest->u_thresh != 0)) {
slow part
}
To hide the effect of burning some CPU cycles you can
use IP_VS_THRESHOLD_UP and IP_VS_THRESHOLD_DOWN macros the will
cover this code :)))) Joking :)
Of course, the locking in 2.4+ is something to think for.
> Cheers,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
