[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200515.102516.536157145939265174.davem@davemloft.net>
Date: Fri, 15 May 2020 10:25:16 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: vladbu@...lanox.com
Cc: netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
jiri@...nulli.us, dcaratti@...hat.com, marcelo.leitner@...il.com,
kuba@...nel.org
Subject: Re: [PATCH net-next v2 0/4] Implement classifier-action terse dump
mode
From: Vlad Buslov <vladbu@...lanox.com>
Date: Fri, 15 May 2020 14:40:10 +0300
> Output rate of current upstream kernel TC filter dump implementation if
> relatively low (~100k rules/sec depending on configuration). This
> constraint impacts performance of software switch implementation that
> rely on TC for their datapath implementation and periodically call TC
> filter dump to update rules stats. Moreover, TC filter dump output a lot
> of static data that don't change during the filter lifecycle (filter
> key, specific action details, etc.) which constitutes significant
> portion of payload on resulting netlink packets and increases amount of
> syscalls necessary to dump all filters on particular Qdisc. In order to
> significantly improve filter dump rate this patch sets implement new
> mode of TC filter dump operation named "terse dump" mode. In this mode
> only parameters necessary to identify the filter (handle, action cookie,
> etc.) and data that can change during filter lifecycle (filter flags,
> action stats, etc.) are preserved in dump output while everything else
> is omitted.
>
> Userspace API is implemented using new TCA_DUMP_FLAGS tlv with only
> available flag value TCA_DUMP_FLAGS_TERSE. Internally, new API requires
> individual classifier support (new tcf_proto_ops->terse_dump()
> callback). Support for action terse dump is implemented in act API and
> don't require changing individual action implementations.
...
This looks fine, so series applied.
But really if people just want an efficient stats dump there is probably
a better way to efficiently encode just the IDs and STATs. Maybe even
put the stats in pages that userland can mmap() and avoid all of this
system call overhead and locking altogether.
Powered by blists - more mailing lists