[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <vbf1rnhpwhe.fsf@mellanox.com>
Date: Mon, 18 May 2020 09:50:53 +0300
From: Vlad Buslov <vladbu@...lanox.com>
To: David Miller <davem@...emloft.net>
Cc: vladbu@...lanox.com, 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
On Fri 15 May 2020 at 20:25, David Miller <davem@...emloft.net> wrote:
> 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.
Thanks! Adding such API will be my next step, if terse dump performance
proves insufficient.
Powered by blists - more mailing lists