[ovs-dev] [PATCH 4/4] conntrack: compact the size of conn structure.
xnhp0320 at gmail.com
Sat Mar 6 03:10:18 UTC 2021
Gaëtan Rivet <grive at u256.net> 于2021年3月3日周三 上午4:01写道：
> On Sun, Nov 29, 2020, at 03:32, hepeng.0320 wrote:
> > From: hepeng <hepeng.0320 at bytedance.com>
> > This patch tries to use ovs_spin_lock as an alternative to reduce the
> > size of each conn. The ovs_mutex_lock consumes 48 bytes while the
> > ovs_spin_lock only uses 16 bytes.
> Using a spin-lock means that the thread won't yield. It might be fine for userland datapath threads, but those are not the only one locking the connections. The ct_clean thread will do, and will execute on randomly assigned CPUs, potentially blocking other threads from being scheduled there. As many conn critical sections are not short, this could impair other modules beyond conntrack.
I guess one way to check if you should use spinlock is to check if
your datapath is polling base or not, the spinlock might be harmful
for AF_XDP userspace datapath, I guess.
since PMD are normally tied into some cores, so the execute time of
the critical section is limited and predictable (as normally some
special optimization like putting isolcpu in the GRUB), so we can
expect that the CT clean thread will not be blocked that long?
I see in DPDK code the spinlock is used in many places, I guess in
certain cases, that we can switch to use spinlock.
Maybe uses pthread_mutex as a default setting, but provide compile
macros as in this patch.
> Gaining some bytes is good, but it needs more thought and opinions. There might be other venues available, less risky, to reduce the size.
> > Also, we remove the alg info into an
> > extra space as alg is not common in the real world userspace ct use case.
> > (mostly used as security group and nat in the cloud).
> Can you submit this as a separate commit?
> > The size of conn_tcp: 312 -> 240.
> > Signed-off-by: Peng He <hepeng.0320 at bytedance.com>
> Gaetan Rivet
> dev mailing list
> dev at openvswitch.org
More information about the dev