|
Hello Horms,
Yes, it is called ipvs-0.1.7-sync_proc.2.patch. Version 2 of the
sync_proc patch for ipvs-0.1.7. If I called it ipvs-0.1.7.patch then I
wouldn't know which patch for ipvs-0.1.7 it was.
What is ipvs-0.1.7?? I apologise to you for my ignorance. I thought it
was against ipvs-1.0.7. The rest is of course pure logic I do the same
way actually.
I have attached ipvs-0.1.7-sync_proc.3.patch fixing the minor spelling
problem you pointed out. Spelling has never been my strong point.
I assume it is correct even though the patch didn't travel all along the
Internet into my mailbox ;).
#define IP_VS_SYNC_PORT 8848 /* multicast port */
I wonder if this should also be made selectable?
Good point.
Can be done in the next round, when this patch is in.
Good plan, this patch is big enough as it is.
And it is nice, clear and straightforward. It doesn't change anything
AFAICT if you do not touch those proc-fs variables. So I think it is
definitely a good patch. With this patch we can also do some tests to
see how far we can stress the synchronisation.
+syncronisation will occur on once the 3rd packet is recieved, and every
Holy cow Horms, where you stoned or did I miss recent advances in
English?
I've reworded this, hopefully it is clearer now.
Yes :). Sorry for being so picky and a general pain in the butt.
I think the previous version was correct, but very wordy.
Of course, I was also more referring to my really picky way of
correcting every little spelling mistake.
+struct ip_vs_sync_mesg {
+ __u8 nr_conns;
+ __u8 reserved;
+ __u16 size;
+
+ /* ip_vs_sync_conn entries start here */
+};
Hehe, I know why nr_conns is __u8. struct ip_vs_sync_mesg will be 4 bytes,
no alignment, no dirty L1 cache lines, simply a nice happy chuck for the
stack, but there is certainly real truth behind this. :)
Well yes and no. The reserved value is never used (in fact it isn't even
initialised). So the structure could easily have been.
struct ip_vs_sync_mesg {
__u16 nr_conns;
__u16 size;
/* ip_vs_sync_conn entries start here */
};
Of course. I would also favour this.
I suspect the reason is more along the lines of aiming for ~1500 byte
packets, in which case nr_conns can't even reach 255, so 1 byte is
Yes.
fine. Unfortunately as the header has no version info, changing
it now could result in some strange behaviour if LVS was running
different versions on different hosts. Though, perhaps this
isn't as much of a problem as I percieve.
Yes.
You confuse me sometimes too :)
ratz@zar:~/down/ipvs > grep VS_STATE_INPUT_ONLY ipvs-0.1.7-sync_proc.*
ipvs-0.1.7-sync_proc.2.patch:+#define VS_STATE_INPUT_ONLY 8
ipvs-0.1.7-sync_proc.2.patch:-#define VS_STATE_INPUT_ONLY 8
ipvs-0.1.7-sync_proc.patch:+#define VS_STATE_INPUT_ONLY 8
ratz@zar:~/down/ipvs >
If you'd moved the VS_STATE_INPUT_ONLY variable in the first patch, I
would see a line with a leading "-" too for it instead of only a line
with a leading "+". Patch 2 correctly reports two occurencies of
VS_STATE_INPUT_ONLY, one with the leading "-" and one with the leading
"+" which indicates a real move.
BTW, the thing about confusion was more or less what I wrote to Martijn
in my last email in Chinese. Actually it is more along the lines of "I'm
pretty darn hard to deal with, I can also be confusing".
#define NR_CONNS (1 << (8 * sizeof((struct ip_vs_sync_mesg *)->nr_conns)))
- 1
I'm not sure what you are getting at there. A convenience macro
for accessing blah->nr_conns ?
Don't worry. I wanted to remove the 255 in the code and replace it with
the calculated amount of connections from the struct, so once we'll
change it to 16bit we wouldn't need to run s/255/16383/g.
Best regards and thank you for your patience,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
|
