All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oz Shlomo <ozsh@nvidia.com>
To: Saeed Mahameed <saeed@kernel.org>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	Ariel Levkovich <lariel@nvidia.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, <netdev@vger.kernel.org>,
	Oz Shlomo <ozsh@mellanox.com>, Roi Dayan <roid@nvidia.com>,
	Marcelo Ricardo Leitner <mleitner@redhat.com>
Subject: Re: [net-next V2 09/15] net/mlx5e: CT: Use the same counter for both directions
Date: Mon, 7 Dec 2020 12:20:54 +0200	[thread overview]
Message-ID: <e98a5a9d-9c65-9687-ca55-dcd266a6cfdf@nvidia.com> (raw)
In-Reply-To: <9b24cd270def8ea5432fc117e4fd1ed9c756a58d.camel@kernel.org>

Hi Marcelo,

On 12/1/2020 11:41 PM, Saeed Mahameed wrote:
> On Fri, 2020-11-27 at 11:01 -0300, Marcelo Ricardo Leitner wrote:
>> On Wed, Sep 23, 2020 at 03:48:18PM -0700, saeed@kernel.org wrote:
>>> From: Oz Shlomo <ozsh@mellanox.com>
>>
>> Sorry for reviving this one, but seemed better for the context.
>>
>>> A connection is represented by two 5-tuple entries, one for each
>>> direction.
>>> Currently, each direction allocates its own hw counter, which is
>>> inefficient as ct aging is managed per connection.
>>>
>>> Share the counter that was allocated for the original direction
>>> with the
>>> reverse direction.
>>
>> Yes, aging is done per connection, but the stats are not. With this
>> patch, with netperf TCP_RR test, I get this: (mangled for
>> readability)
>>
>> # grep 172.0.0.4 /proc/net/nf_conntrack
>> ipv4     2 tcp      6
>>    src=172.0.0.3 dst=172.0.0.4 sport=34018 dport=33396 packets=3941992
>> bytes=264113427
>>    src=172.0.0.4 dst=172.0.0.3 sport=33396 dport=34018 packets=4
>> bytes=218 [HW_OFFLOAD]
>>    mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=0 use=3
>>
>> while without it (594e31bceb + act_ct patch to enable it posted
>> yesterday + revert), I get:
>>
>> # grep 172.0.0.4 /proc/net/nf_conntrack
>> ipv4     2 tcp      6
>>    src=172.0.0.3 dst=172.0.0.4 sport=41856 dport=32776 packets=1876763
>> bytes=125743084
>>    src=172.0.0.4 dst=172.0.0.3 sport=32776 dport=41856 packets=1876761
>> bytes=125742951 [HW_OFFLOAD]
>>    mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=0 use=3
>>
>> The same is visible on 'ovs-appctl dpctl/dump-conntrack -s' then.
>> Summing both directions in one like this is at least very misleading.
>> Seems this change was motivated only by hw resources constrains. That
>> said, I'm wondering, can this change be reverted somehow?
>>
>>    Marcelo
> 
> Hi Marcelo, thanks for the report,
> Sorry i am not familiar with this /procfs
> Oz, Ariel, Roi, what is your take on this, it seems that we changed the
> behavior of stats incorrectly.

Indeed we overlooked the CT accounting extension.
We will submit a driver fix.

> 
> Thanks,
> Saeed.
> 
> 


  reply	other threads:[~2020-12-07 10:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 22:48 [pull request][net-next V2 00/15] mlx5 Connection Tracking in NIC mode saeed
2020-09-23 22:48 ` [net-next V2 01/15] net/mlx5: Refactor multi chains and prios support saeed
2020-09-23 22:48 ` [net-next V2 02/15] net/mlx5: Allow ft level ignore for nic rx tables saeed
2020-09-23 22:48 ` [net-next V2 03/15] net/mlx5e: Tc nic flows to use mlx5_chains flow tables saeed
2020-09-23 22:48 ` [net-next V2 04/15] net/mlx5e: Split nic tc flow allocation and creation saeed
2020-09-23 22:48 ` [net-next V2 05/15] net/mlx5: Refactor tc flow attributes structure saeed
2020-09-23 22:48 ` [net-next V2 06/15] net/mlx5e: Add tc chains offload support for nic flows saeed
2020-09-23 22:48 ` [net-next V2 07/15] net/mlx5e: rework ct offload init messages saeed
2020-09-23 22:48 ` [net-next V2 08/15] net/mlx5e: Support CT offload for tc nic flows saeed
2020-09-23 22:48 ` [net-next V2 09/15] net/mlx5e: CT: Use the same counter for both directions saeed
2020-11-27 14:01   ` Marcelo Ricardo Leitner
2020-12-01 21:41     ` Saeed Mahameed
2020-12-07 10:20       ` Oz Shlomo [this message]
2020-12-07 19:19         ` Marcelo Ricardo Leitner
2020-09-23 22:48 ` [net-next V2 10/15] net/mlx5e: TC: Remove unused parameter from mlx5_tc_ct_add_no_trk_match() saeed
2020-09-23 22:48 ` [net-next V2 11/15] net/mlx5e: Keep direct reference to mlx5_core_dev in tc ct saeed
2020-09-23 22:48 ` [net-next V2 12/15] net/mlx5e: IPsec: Use kvfree() for memory allocated with kvzalloc() saeed
2020-09-23 22:48 ` [net-next V2 13/15] net/mlx5e: Use kfree() to free fd->g in accel_fs_tcp_create_groups() saeed
2020-09-23 22:48 ` [net-next V2 14/15] net/mlx5: simplify the return expression of mlx5_ec_init() saeed
2020-09-23 22:48 ` [net-next V2 15/15] net/mlx5: remove unreachable return saeed
2020-09-25  2:55 ` [pull request][net-next V2 00/15] mlx5 Connection Tracking in NIC mode David Miller

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=e98a5a9d-9c65-9687-ca55-dcd266a6cfdf@nvidia.com \
    --to=ozsh@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=lariel@nvidia.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=mleitner@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=ozsh@mellanox.com \
    --cc=roid@nvidia.com \
    --cc=saeed@kernel.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.