On Fri, 2020-11-27 at 11:01 -0300, Marcelo Ricardo Leitner wrote: > On Wed, Sep 23, 2020 at 03:48:18PM -0700, [email protected] wrote: > > From: Oz Shlomo <[email protected]> > > 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. Thanks, Saeed.
