LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [PATCH RFC] ipvs: reschedule new connections if previous was on FIN_

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [PATCH RFC] ipvs: reschedule new connections if previous was on FIN_WAIT or TIME_WAIT
Cc: lvs-devel@xxxxxxxxxxxxxxx, hannes@xxxxxxxxxx, jbrouer@xxxxxxxxxx
From: Marcelo Ricardo Leitner <mleitner@xxxxxxxxxx>
Date: Wed, 07 Jan 2015 13:52:24 -0200
Hi,

On 06-01-2015 19:06, Julian Anastasov wrote:

        Hello,

On Tue, 6 Jan 2015, Marcelo Ricardo Leitner wrote:

        I guess, we here try to avoid old sync message to
expire new connection. The problem is that UDP conns and
templates are always IP_VS_CONN_F_INACTIVE, may be a TCP+SCTP
protocol check is needed.

Yes, that's the idea, avoiding the old sync messages. I don't think we need a
check for protocol here because the outer if() (the one that checks daddr and
dport) wouldn't happen for UDP, right? Unless it was really recycled.. But
yeah I missed the template case. Perhaps we can just move this block together
with the previous if(!).

        OK, just make sure patch has short lines (80):

# scripts/checkpatch.pl --strict /tmp/file.patch

Sure thing


         if (!(flags & IP_VS_CONN_F_TEMPLATE)) {
                 cp = ip_vs_conn_in_get(param);
                 if (cp && ((cp->dport != dport) ||
                            !ip_vs_addr_equal(cp->daf, &cp->daddr, daddr))) {
                         if (!(flags & IP_VS_CONN_F_INACTIVE)) {
                                 ip_vs_conn_expire_now(cp);
                                 __ip_vs_conn_put(cp);
                                 cp = NULL;
                         } else {

        I assume we will not stop here sync for some connection that
was normally expired in master but was delayed in backup. TCP sync
starts for EST state, so I think it will hit the above case.

You mean that we could end up ignoring a sync msg that we shouldn't ignore?

Cheers,
Marcelo

--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

<Prev in Thread] Current Thread [Next in Thread>