Hello, Not sure if we need "-b". I guess it is difficult to maintain many options, may be one option --sched-flags should be enough, for example: --sched-flags sh-fallback,sh-port In all cases we sho
Hello, May be I have to remove this ip_vs_fill_iph_addr_only function, we should provide iph to schedulers. I'll post patch this weekend. Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe fro
Hi, I've patched ipvsadm and fixed up the kernel patch. For the ipvsadm option, I've used (-b|--sched-flags) 123. I don't particularly like this style, but I wanted something working for testing. I'm
Hi, In order for this to work, I would have to change ip_vs_fill_iph_addr_only in ip_vs_sh_schedule to ip_vs_fill_iph_skb (or add an ip_vs_fill_iph_addr_proto_only function). Obviously, I can do this
Hi, Do you have any preferences for the command-line syntax to set the flags? --sched-flag-1 --sched-flag-2, --sched-flag 1 --sched-flag 2, --sched-flags 12, something else? Options 2 and 3 mean we c
Hello, Risky means: we break the rules of persistence, one established connection can continue to work during weight=0 and we create new connection to another real server. Users can set weight=0 for
Hi, Fair enough, although I would guess two connections from the same IP going to different servers wouldn't be an issue in many cases. Can you elaborate on what you mean by "risky" here? Indeed. But
Hi, I've incorporated your changes and sent a separate email with the patch. Thanks for your help! Alex -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a messag
Hello, Above change can be (all on same line): - if ((sch->type == SCTP_CID_INIT) && + if ((sysctl_sloppy_sctp(ipvs) || sch->type == SCTP_CID_INIT) && Here is the SCTP part we can use: diff --git a/n
Hello, I'm not sure how SH is used, may be failed dests are removed from the list to avoid connection failures. The problem is that every move leads to problems: - add/remove destination => mapping i
Hi, Updated patch, including your changes from the last email: diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h index 4405886..22bea5d 100644 -- a/include/net/ip_vs.h +++ b/include/net/ip_vs.h
Hi, Is it worth looking at changing this? Or is this going to be too difficult a change to push through? I just don't understand why rejecting a client connection when there are servers available is
Hello, Please post patches inline, not as attached file. Refer to Documentation/email-clients.txt for details about your email client. The check for initial sSR state should be in set_tcp_state() and
Hello, Yes, if we find a way to configure SH, there is no need for separate SHP. Agreed. I don't know, the authors preferred this behaviour. Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe
Hi, Attached is a patch for sloppy TCP and SCTP against the upstream kernel. checkpatch.pl throws up errors, but they refer to stuff that was there before, not my changes. I've added a bit of code to
Hi, Well, this one can be configured per service by changing the scheduler. Or are you concerned about the fact that the code for SHP and SH is essentially the same and should be merged? I don't thin
Hi, I'll have to read the code a bit more to completely understand that, but it seems to make sense! Make sense. The problem is that switchover won't necessarily be controlled if a server fails. Alex
Hello, Agreed, if we don't find big problems with the Sloppy TCP mode the only problem will be what happens with netfilter conntracks. But it is a problem even now, even if we create sync conn in bac
May be better to modify the sync algorithm to synchronize only persistence templates for these specific cases? Is it possible at all? May be, with some flag and also sloppy_tcp. Then the parametrize