From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Vlad Buslov <vladbu@nvidia.com>
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us,
ozsh@nvidia.com, marcelo.leitner@gmail.com,
simon.horman@corigine.com
Subject: Re: [PATCH net-next v3 2/7] netfilter: flowtable: fixup UDP timeout depending on ct state
Date: Fri, 20 Jan 2023 12:57:59 +0100 [thread overview]
Message-ID: <Y8qBx6gOJJH2Y7FE@salvia> (raw)
In-Reply-To: <20230119195104.3371966-3-vladbu@nvidia.com>
On Thu, Jan 19, 2023 at 08:50:59PM +0100, Vlad Buslov wrote:
> Currently flow_offload_fixup_ct() function assumes that only replied UDP
> connections can be offloaded and hardcodes UDP_CT_REPLIED timeout value. To
> enable UDP NEW connection offload in following patches extract the actual
> connections state from ct->status and set the timeout according to it.
>
> Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
> ---
> net/netfilter/nf_flow_table_core.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
> index 81c26a96c30b..04bd0ed4d2ae 100644
> --- a/net/netfilter/nf_flow_table_core.c
> +++ b/net/netfilter/nf_flow_table_core.c
> @@ -193,8 +193,11 @@ static void flow_offload_fixup_ct(struct nf_conn *ct)
> timeout -= tn->offload_timeout;
> } else if (l4num == IPPROTO_UDP) {
> struct nf_udp_net *tn = nf_udp_pernet(net);
> + enum udp_conntrack state =
> + test_bit(IPS_SEEN_REPLY_BIT, &ct->status) ?
> + UDP_CT_REPLIED : UDP_CT_UNREPLIED;
>
> - timeout = tn->timeouts[UDP_CT_REPLIED];
> + timeout = tn->timeouts[state];
> timeout -= tn->offload_timeout;
For netfilter's flowtable (not talking about act_ct), this is a
"problem" because the flowtable path update with ct->status flags.
In other words, for netfilter's flowtable UDP_CT_UNREPLIED timeout
will be always used for UDP traffic if it is offloaded and no traffic
from the classic path was seen.
If packets go via hardware offload, the host does not see packets in
the reply direction (unless hardware counters are used to set on
IPS_SEEN_REPLY_BIT?).
Then, there is also IPS_ASSURED: Netfilter's flowtable assumes that
TCP flows are only offloaded to hardware if IPS_ASSURED.
next prev parent reply other threads:[~2023-01-20 11:58 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 [this message]
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
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=Y8qBx6gOJJH2Y7FE@salvia \
--to=pablo@netfilter.org \
--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=simon.horman@corigine.com \
--cc=vladbu@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).