All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Vlad Buslov <vladbu@nvidia.com>
Cc: <davem@davemloft.net>, <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>,
	<marcelo.leitner@gmail.com>, <simon.horman@corigine.com>
Subject: Re: [PATCH net-next v4 6/7] net/sched: act_ct: offload UDP NEW connections
Date: Tue, 24 Jan 2023 21:42:10 -0800	[thread overview]
Message-ID: <20230124214210.32ac7329@kernel.org> (raw)
In-Reply-To: <20230124140207.3975283-7-vladbu@nvidia.com>

On Tue, 24 Jan 2023 15:02:06 +0100 Vlad Buslov wrote:
> Modify the offload algorithm of UDP connections to the following:
> 
> - Offload NEW connection as unidirectional.
> 
> - When connection state changes to ESTABLISHED also update the hardware
> flow. However, in order to prevent act_ct from spamming offload add wq for
> every packet coming in reply direction in this state verify whether
> connection has already been updated to ESTABLISHED in the drivers. If that
> it the case, then skip flow_table and let conntrack handle such packets
> which will also allow conntrack to potentially promote the connection to
> ASSURED.
> 
> - When connection state changes to ASSURED set the flow_table flow
> NF_FLOW_HW_BIDIRECTIONAL flag which will cause refresh mechanism to offload
> the reply direction.
> 
> All other protocols have their offload algorithm preserved and are always
> offloaded as bidirectional.
> 
> Note that this change tries to minimize the load on flow_table add
> workqueue. First, it tracks the last ctinfo that was offloaded by using new
> flow 'ext_data' field and doesn't schedule the refresh for reply direction
> packets when the offloads have already been updated with current ctinfo.
> Second, when 'add' task executes on workqueue it always update the offload
> with current flow state (by checking 'bidirectional' flow flag and
> obtaining actual ctinfo/cookie through meta action instead of caching any
> of these from the moment of scheduling the 'add' work) preventing the need
> from scheduling more updates if state changed concurrently while the 'add'
> work was pending on workqueue.

Clang is not happy:

net/sched/act_ct.c:677:12: warning: cast to smaller integer type 'enum ip_conntrack_info' from 'typeof (_Generic((flow->ext_data), char: (char)0, unsigned char: (unsigned char)0, signed char: (signed char)0, unsigned short: (unsigned short)0, short: (short)0, unsigned int: (unsigned int)0, int: (int)0, unsigned long: (unsigned long)0, long: (long)0, unsigned long long: (unsigned long long)0, long long: (long long)0, default: (flow->ext_data)))' (aka 'void *') [-Wvoid-pointer-to-enum-cast]
                else if ((enum ip_conntrack_info)READ_ONCE(flow->ext_data) ==
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  reply	other threads:[~2023-01-25  5:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 14:02 [PATCH net-next v4 0/7] Allow offloading of UDP NEW connections via act_ct Vlad Buslov
2023-01-24 14:02 ` [PATCH net-next v4 1/7] net: flow_offload: provision conntrack info in ct_metadata Vlad Buslov
2023-01-24 14:02 ` [PATCH net-next v4 2/7] netfilter: flowtable: fixup UDP timeout depending on ct state Vlad Buslov
2023-01-24 14:02 ` [PATCH net-next v4 3/7] netfilter: flowtable: allow unidirectional rules Vlad Buslov
2023-01-24 14:02 ` [PATCH net-next v4 4/7] netfilter: flowtable: save ctinfo in flow_offload Vlad Buslov
2023-01-24 14:02 ` [PATCH net-next v4 5/7] net/sched: act_ct: set ctinfo in meta action depending on ct state Vlad Buslov
2023-01-24 14:02 ` [PATCH net-next v4 6/7] net/sched: act_ct: offload UDP NEW connections Vlad Buslov
2023-01-25  5:42   ` Jakub Kicinski [this message]
2023-01-26 17:12     ` Vlad Buslov
2023-01-24 14:02 ` [PATCH net-next v4 7/7] netfilter: nf_conntrack: allow early drop of offloaded UDP conns Vlad Buslov

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=20230124214210.32ac7329@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --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=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 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.