[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210201152534.GJ12443@breakpoint.cc>
Date: Mon, 1 Feb 2021 16:25:34 +0100
From: Florian Westphal <fw@...len.de>
To: Roi Dayan <roid@...dia.com>
Cc: Florian Westphal <fw@...len.de>,
Pablo Neira Ayuso <pablo@...filter.org>,
netdev@...r.kernel.org, Paul Blakey <paulb@...dia.com>,
Oz Shlomo <ozsh@...dia.com>
Subject: Re: [PATCH net 1/1] netfilter: conntrack: Check offload bit on table
dump
Roi Dayan <roid@...dia.com> wrote:
> > TCP initial timeout is one minute, UDP 30 seconds.
> > That should surely be enough to do flow_offload_add (which extends
> > the timeout)?
>
> Yes, flow_offload_add() extends the timeout. but it needs to finish.
>
> >
> > Maybe something is doing flow_offload_add() for unconfirmed conntrack?
> >
> > In unconfirmed conntrack case, ct->timeout is absolute timeout value, e.g. for
> > tcp it will be set to 60 * HZ.
>
> When I hit the issue I printed jiffies and ct->timeout and saw they are
> the same or very close but not an absolute number.
Thats strange, for new flows they should not be close at all.
UDP sets a 30 second timeout, TCP sets a 60 second initial timeout.
Do you think rhashtable_insert_fast() in flow_offload_add() blocks for
dozens of seconds?
Thats about the only thing I can see between 'offload bit gets set'
and 'timeout is extended' in flow_offload_add() that could at least
spend *some* time.
> We hit this issue before more easily and pushed this fix
>
> 4203b19c2796 netfilter: flowtable: Set offload timeout when adding flow
This fix makes sense to me.
Powered by blists - more mailing lists