From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Oz Shlomo <ozsh@nvidia.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Roi Dayan <roid@nvidia.com>, Saeed Mahameed <saeed@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Paul Blakey <paulb@nvidia.com>,
Saeed Mahameed <saeedm@nvidia.com>
Subject: Re: [net-next 08/15] net/mlx5e: CT: Preparation for offloading +trk+new ct rules
Date: Fri, 22 Jan 2021 02:18:34 +0100 [thread overview]
Message-ID: <20210122011834.GA25356@salvia> (raw)
In-Reply-To: <009bd8cf-df39-5346-b892-4e68a042c4b4@nvidia.com>
Hi Oz,
On Wed, Jan 20, 2021 at 06:09:48PM +0200, Oz Shlomo wrote:
> On 1/14/2021 11:50 PM, Marcelo Ricardo Leitner wrote:
> >
> > Thoughts?
> >
>
> I wonder if we should develop a generic mechanism to optimize CT software
> for a use case that is faulty by design.
> This has limited value for software as it would only reduce the conntrack
> table size (packet classification is still required).
> However, this feature may have a big impact on hardware offload.
> Normally hardware offload relies on software to handle new connections.
> Causing all new connections to be processed by software.
> With this patch the hardware may autonomously set the +new connection state
> for the relevant connections.
Could you fix this issue with unidirectional flows by checking for
IPS_CONFIRMED status bit? The idea is to hardware offload the entry
after the first packet goes through software successfully. Then, there
is no need to wait for the established state that requires to see
traffic in both directions.
next prev parent reply other threads:[~2021-01-22 1:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 5:30 [pull request][net-next 00/15] mlx5 updates 2021-01-07 Saeed Mahameed
2021-01-08 5:30 ` [net-next 01/15] net/mlx5: Add HW definition of reg_c_preserve Saeed Mahameed
2021-01-08 5:30 ` [net-next 02/15] net/mlx5e: Simplify condition on esw_vport_enable_qos() Saeed Mahameed
2021-01-08 5:30 ` [net-next 03/15] net/mlx5: E-Switch, use new cap as condition for mpls over udp Saeed Mahameed
2021-01-08 5:30 ` [net-next 04/15] net/mlx5e: E-Switch, Offload all chain 0 priorities when modify header and forward action is not supported Saeed Mahameed
2021-01-08 5:30 ` [net-next 05/15] net/mlx5e: CT: Pass null instead of zero spec Saeed Mahameed
2021-01-08 5:30 ` [net-next 06/15] net/mlx5e: Remove redundant initialization to null Saeed Mahameed
2021-01-08 5:30 ` [net-next 07/15] net/mlx5e: CT: Remove redundant usage of zone mask Saeed Mahameed
2021-01-08 5:30 ` [net-next 08/15] net/mlx5e: CT: Preparation for offloading +trk+new ct rules Saeed Mahameed
2021-01-08 21:48 ` Marcelo Ricardo Leitner
2021-01-10 7:45 ` Roi Dayan
2021-01-10 7:52 ` Roi Dayan
2021-01-11 23:51 ` Marcelo Ricardo Leitner
2021-01-12 9:27 ` Oz Shlomo
2021-01-14 13:02 ` Marcelo Ricardo Leitner
2021-01-14 14:03 ` Oz Shlomo
2021-01-14 21:50 ` Marcelo Ricardo Leitner
2021-01-20 16:09 ` Oz Shlomo
2021-01-22 1:18 ` Pablo Neira Ayuso [this message]
2021-01-22 2:16 ` Marcelo Ricardo Leitner
2021-01-25 9:15 ` Oz Shlomo
2021-01-08 5:30 ` [net-next 09/15] net/mlx5e: CT: Support offload of " Saeed Mahameed
2021-01-08 21:59 ` Marcelo Ricardo Leitner
2021-01-10 7:55 ` Roi Dayan
2021-01-08 5:30 ` [net-next 10/15] net/mlx5e: CT: Add support for mirroring Saeed Mahameed
2021-01-08 5:30 ` [net-next 11/15] net/mlx5e: CT, Avoid false lock depenency warning Saeed Mahameed
2021-01-08 5:30 ` [net-next 12/15] net/mlx5e: IPsec, Enclose csum logic under ipsec config Saeed Mahameed
2021-01-08 5:30 ` [net-next 13/15] net/mlx5e: IPsec, Avoid unreachable return Saeed Mahameed
2021-01-08 5:30 ` [net-next 14/15] net/mlx5e: IPsec, Inline feature_check fast-path function Saeed Mahameed
2021-01-08 5:30 ` [net-next 15/15] net/mlx5e: IPsec, Remove unnecessary config flag usage Saeed Mahameed
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=20210122011834.GA25356@salvia \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=ozsh@nvidia.com \
--cc=paulb@nvidia.com \
--cc=roid@nvidia.com \
--cc=saeed@kernel.org \
--cc=saeedm@nvidia.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).