All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Lilja <michael.lilja@gmail.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Jozsef Kadlecsik <kadlec@netfilter.org>,
	Florian Westphal <fw@strlen.de>,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	coreteam@netfilter.org
Subject: Re: [PATCH] Periodically flow expire from flow offload tables
Date: Wed, 26 Oct 2022 19:36:22 +0200	[thread overview]
Message-ID: <25246B91-B5BE-43CA-9D98-67950F17F0A1@gmail.com> (raw)
In-Reply-To: <Y1kQ9FhrwxCKIdoe@salvia>

Hi,

I will look to use the flowable netlink interface. I have not yet, but does this possible give the option of doing something like this:

flowtable ft {
	hook ingress priority filter
	devices = { lan1, lan2, wan }
	flags offload, timeout
}


I would say the above it the most flexible, I just didn’t explore that, it would kinda be like with ’sets’ where you can specify a timeout on when the entries should expire?


With regards to the IPS_OPPLOAD clear in flow_offload_del() then I added that because I saw some weird timeout side effects due to flow_offload_fixup_ct(), but I can re-investigate, it could be that it was early in my investigations and some of the other changes I made has made it obsolete.

Thanks
Michael


  reply	other threads:[~2022-10-26 17:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-23 17:16 [PATCH] Periodically flow expire from flow offload tables Michael Lilja
2022-10-25 11:05 ` Pablo Neira Ayuso
2022-10-25 12:36   ` Michael Lilja
2022-10-25 13:00     ` Pablo Neira Ayuso
2022-10-25 13:32       ` Michael Lilja
2022-10-26 10:50         ` Pablo Neira Ayuso
2022-10-26 17:36           ` Michael Lilja [this message]
2022-10-26 19:40             ` Michael Lilja
2022-11-02 18:52               ` Pablo Neira Ayuso
2022-11-02 19:52                 ` Michael Lilja

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=25246B91-B5BE-43CA-9D98-67950F17F0A1@gmail.com \
    --to=michael.lilja@gmail.com \
    --cc=corbet@lwn.net \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=kadlec@netfilter.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    /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.