On Thu, Jul 02, 2020 at 11:18:29AM +0200, Simon Horman wrote: > On Wed, Jul 01, 2020 at 06:17:19PM +0300, Julian Anastasov wrote: > > YangYuxi is reporting that connection reuse > > is causing one-second delay when SYN hits > > existing connection in TIME_WAIT state. > > Such delay was added to give time to expire > > both the IPVS connection and the corresponding > > conntrack. This was considered a rare case > > at that time but it is causing problem for > > some environments such as Kubernetes. > > > > As nf_conntrack_tcp_packet() can decide to > > release the conntrack in TIME_WAIT state and > > to replace it with a fresh NEW conntrack, we > > can use this to allow rescheduling just by > > tuning our check: if the conntrack is > > confirmed we can not schedule it to different > > real server and the one-second delay still > > applies but if new conntrack was created, > > we are free to select new real server without > > any delays. > > > > YangYuxi lists some of the problem reports: > > > > - One second connection delay in masquerading mode: > > https://marc.info/?t=151683118100004&r=1&w=2 > > > > - IPVS low throughput #70747 > > https://github.com/kubernetes/kubernetes/issues/70747 > > > > - Apache Bench can fill up ipvs service proxy in seconds #544 > > https://github.com/cloudnativelabs/kube-router/issues/544 > > > > - Additional 1s latency in `host -> service IP -> pod` > > https://github.com/kubernetes/kubernetes/issues/90854 > > > > Fixes: f719e3754ee2 ("ipvs: drop first packet to redirect conntrack") > > Co-developed-by: YangYuxi <yx.atom1@xxxxxxxxx> > > Signed-off-by: YangYuxi <yx.atom1@xxxxxxxxx> > > Signed-off-by: Julian Anastasov <ja@xxxxxx> > > Thanks, this looks good to me. > > Reviewed-by: Simon Horman <horms@xxxxxxxxxxxx> > > Pablo, could you consider applying this to nf-next? Applied, thanks.
