|
Hello Julian,
Long time no talk, hope you're doing good.
>>You've recently introduced the IP_VS_CONN_F_TEMPLATE flag in 2.4.x and
>>2.6.x, however in the ip_vs_bind_dest() function we have a significant
>>difference between 2.6.x and 2.4.x. Why is the dest->inactconns counter
>>in 2.4.x kernel not incremented for non template connections in
>>ip_vs_bind_dest()?
>
> May be because this code is older, Wensong moved the increment
> into ip_vs_bind_dest for the 2.6 version and introduced dest->persistconns.
Which is not used, I believe :). I have backported this as well. Might
come in handy one day when we do per template threshold limitation.
> Before that change (referring to 2.4), every ip_vs_conn_new caller
> incremented this counter except for templates, which is ugly.
Upon entry, we call ip_vs_schedule() which in turn, iff
IP_VS_SVC_F_PERSISTENT is set, calls ip_vs_sched_persist(). This is the
same for 2.4.x and 2.6.x. In fact almost everything is the same except
the point you mentioned with the refcnt. So, why on earth hasn't this
been backported to 2.4.x? The mode as I see it is as follows:
2.4.x:
------
ip_vs_schedule() -> ip_vs_conn_new() -> ip_vs_bind_dest()
| -> atomic_inc(&dest->inactconns) in ip_vs_schedule()
|
+---> ip_vs_sched_persist() -> ip_vs_conn_new()
-> ip_vs_bind_dest()
-> atomic_inc(&dest->inactconns) in ip_vs_sched_persist()
atomic_inc(&dest->inactconns) is in two functions here, with two code
control paths.
2.6.x:
------
ip_vs_schedule() -> ip_vs_conn_new() -> ip_vs_bind_dest()
| -> atomic_inc(&dest->inactconns) in ip_vs_bind_dest()
|
+---> ip_vs_sched_persist() -> ip_vs_conn_new()
-> ip_vs_bind_dest()
-> atomic_inc(&dest->inactconns) in ip_vs_bind_dest()
atomic_inc(&dest->inactconns) is in one function in the code control
path and is also symmetric to the decrement.
ip_vs_unbind_dest() decrements the &dest->inactconns counter upon being
called from ip_vs_conn_expire(), which is identical for 2.4.x and 2.6.x.
So indeed, in 2.4.x we have a rather unfortunate symmetry regarding
inactive counter handling.
What hinders us to remove the atomic_inc(&dest->inactconns) calls in
ip_vs_schedule() and ip_vs_sched_persist() and move the bloody thing
into ip_vs_bind_dest() where it belongs? Honestly :)
>>I can hardly imagine this being a bug since a lot more people using
>>2.4.x would barf. I am just not so fluent anymore with the IPVS code,
>>that's why I ask you directly.
>
> The dest->inactconns usage in 2.4 should be correct, it does not
> account templates as the value is used in schedulers.
I really think this should be changed in 2.4.x as well. I'll ship my
kernel with these changes. This also allows us to easier maintain the
not-so-big gap between IPVS-2.4 and IPVS-2.6. Please don't abandon IPVS-2.4.
The code is mostly simple if you overread the skb handling and the timer
stuff :).
Best regards,
Roberto Nibali, ratz
--
-------------------------------------------------------------
addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355
http://www.terreactive.com fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG Wir sichern Ihren Erfolg
-------------------------------------------------------------
|
