All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: "Maciej Żenczykowski" <zenczykowski@gmail.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	Florian Westphal <fw@strlen.de>,
	Linux Network Development Mailing List  <netdev@vger.kernel.org>,
	Netfilter Development Mailing List 
	<netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH netfilter] netfilter: conntrack: udp: generate event on switch to stream timeout
Date: Fri, 15 Oct 2021 11:57:16 +0200	[thread overview]
Message-ID: <20211015095716.GH2942@breakpoint.cc> (raw)
In-Reply-To: <CANP3RGdCBzjWuK8FfHOOKcFAbd_Zru=DkOBBpD3d_PYDR91P5g@mail.gmail.com>

Maciej Żenczykowski <zenczykowski@gmail.com> wrote:
> > Hm, I still don't understand why do you need this extra 3rd
> > update/assured event event. Could you explain your usecase?
> 
> Currently we populate a flow offload array on the assured event, and
> thus the flow in both directions starts bypassing the kernel.
> Hence conntrack timeout is no longer automatically refreshed - and
> there is no opportunity for the timeout to get bumped to the stream
> timeout of 120s - it stays at 30s.
> We periodically (every just over 60-ish seconds) check whether packets
> on a flow have been offloaded, and if so refresh the conntrack
> timeout.  This isn't cheap and we don't want to do it even more often.
> However this 60s cycle > 30s non-stream udp timeout, so the kernel
> conntrack entry expires (and we must thus clear out the flow from the
> offload).  This results in a broken udp stream - but only on newer
> kernels.  Older kernels don't have this '2s' wait feature (which makes
> a lot of sense btw.) but as a result of this the conntrack assured
> event happens at the right time - when the timeout hits 120s (or 180s
> on even older kernels).
> 
> By generating another assured event when the udp stream is 'confirmed'
> and the timeout is boosted from 30s to 120s we have an opportunity to
> ignore the first one (with timeout 30) and only populate the offload
> on the second one (with timeout 120).
> 
> I'm not sure if I'm doing a good job of describing this.  Ask again if
> it's not clear and I'll try again.

Thanks for explaining, no objections to this from my side.

Do you think it makes sense to just delay setting the ASSURED bit
until after the 2s period?

  reply	other threads:[~2021-10-15  9:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15  9:09 [PATCH netfilter] netfilter: conntrack: udp: generate event on switch to stream timeout Maciej Żenczykowski
2021-10-15  9:30 ` Pablo Neira Ayuso
2021-10-15  9:50   ` Maciej Żenczykowski
2021-10-15  9:57     ` Florian Westphal [this message]
2021-10-15 10:15       ` Maciej Żenczykowski
2021-10-15 10:50         ` Florian Westphal
2021-10-17 22:04         ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211015095716.GH2942@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=zenczykowski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.