From: Vlad Buslov <vladbu@nvidia.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: <davem@davemloft.net>, <kuba@kernel.org>, <pabeni@redhat.com>,
<pablo@netfilter.org>, <netdev@vger.kernel.org>,
<netfilter-devel@vger.kernel.org>, <jhs@mojatatu.com>,
<xiyou.wangcong@gmail.com>, <jiri@resnulli.us>, <ozsh@nvidia.com>,
<simon.horman@corigine.com>
Subject: Re: [PATCH net-next v3 0/7] Allow offloading of UDP NEW connections via act_ct
Date: Fri, 20 Jan 2023 08:38:30 +0200 [thread overview]
Message-ID: <87k01hbtbs.fsf@nvidia.com> (raw)
In-Reply-To: <Y8m4A7GchYdx21/h@t14s.localdomain>
On Thu 19 Jan 2023 at 18:37, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> On Thu, Jan 19, 2023 at 08:50:57PM +0100, Vlad Buslov wrote:
>> Currently only bidirectional established connections can be offloaded
>> via act_ct. Such approach allows to hardcode a lot of assumptions into
>> act_ct, flow_table and flow_offload intermediate layer codes. In order
>> to enabled offloading of unidirectional UDP NEW connections start with
>> incrementally changing the following assumptions:
>>
>> - Drivers assume that only established connections are offloaded and
>> don't support updating existing connections. Extract ctinfo from meta
>> action cookie and refuse offloading of new connections in the drivers.
>
> Hi Vlad,
>
> Regarding ct_seq_show(). When dumping the CT entries today, it will do
> things like:
>
> if (!test_bit(IPS_OFFLOAD_BIT, &ct->status))
> seq_printf(s, "%ld ", nf_ct_expires(ct) / HZ);
>
> omit the timeout, which is okay with this new patchset, but then:
>
> if (test_bit(IPS_HW_OFFLOAD_BIT, &ct->status))
> seq_puts(s, "[HW_OFFLOAD] ");
> else if (test_bit(IPS_OFFLOAD_BIT, &ct->status))
> seq_puts(s, "[OFFLOAD] ");
> else if (test_bit(IPS_ASSURED_BIT, &ct->status))
> seq_puts(s, "[ASSURED] ");
>
> Previously, in order to be offloaded, it had to be Assured. But not
> anymore after this patchset. Thoughts?
Hi Marcelo,
I know that for some reason offloaded entries no longer display
'assured' flag in the dump. This could be changed, but I don't have a
preference either way and this patch set doesn't modify the behavior.
Up to you and maintainers I guess.
next prev parent reply other threads:[~2023-01-20 6:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 19:50 [PATCH net-next v3 0/7] Allow offloading of UDP NEW connections via act_ct Vlad Buslov
2023-01-19 19:50 ` [PATCH net-next v3 1/7] net: flow_offload: provision conntrack info in ct_metadata Vlad Buslov
2023-01-19 19:50 ` [PATCH net-next v3 2/7] netfilter: flowtable: fixup UDP timeout depending on ct state Vlad Buslov
2023-01-20 11:57 ` Pablo Neira Ayuso
2023-01-24 7:08 ` Vlad Buslov
2023-01-19 19:51 ` [PATCH net-next v3 3/7] netfilter: flowtable: allow unidirectional rules Vlad Buslov
2023-01-19 19:51 ` [PATCH net-next v3 4/7] netfilter: flowtable: allow updating offloaded rules asynchronously Vlad Buslov
2023-01-20 11:41 ` Pablo Neira Ayuso
2023-01-24 7:06 ` Vlad Buslov
2023-01-24 8:41 ` Pablo Neira Ayuso
2023-01-24 9:19 ` Vlad Buslov
2023-01-24 13:57 ` Vlad Buslov
2023-01-19 19:51 ` [PATCH net-next v3 5/7] net/sched: act_ct: set ctinfo in meta action depending on ct state Vlad Buslov
2023-01-19 19:51 ` [PATCH net-next v3 6/7] net/sched: act_ct: offload UDP NEW connections Vlad Buslov
2023-01-19 19:51 ` [PATCH net-next v3 7/7] netfilter: nf_conntrack: allow early drop of offloaded UDP conns Vlad Buslov
2023-01-19 21:37 ` [PATCH net-next v3 0/7] Allow offloading of UDP NEW connections via act_ct Marcelo Ricardo Leitner
2023-01-20 6:38 ` Vlad Buslov [this message]
2023-01-20 6:57 ` Vlad Buslov
2023-01-20 11:30 ` Marcelo Ricardo Leitner
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=87k01hbtbs.fsf@nvidia.com \
--to=vladbu@nvidia.com \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=ozsh@nvidia.com \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=simon.horman@corigine.com \
--cc=xiyou.wangcong@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.