[ovs-dev] [PATCH v12 0/5] dpcls func ptrs & optimizations
i.maximets at samsung.com
Wed Jul 17 16:26:01 UTC 2019
On 17.07.2019 19:16, Van Haaren, Harry wrote:
>> -----Original Message-----
>> From: Ilya Maximets [mailto:i.maximets at samsung.com]
>> Sent: Wednesday, July 17, 2019 4:03 PM
>> To: Van Haaren, Harry <harry.van.haaren at intel.com>; dev at openvswitch.org
>> Cc: echaudro at redhat.com; malvika.gupta at arm.com; Stokes, Ian
>> <ian.stokes at intel.com>
>> Subject: Re: [PATCH v12 0/5] dpcls func ptrs & optimizations
>> On 17.07.2019 16:00, Harry van Haaren wrote:
>>> Hey Folks,
>>> Here a v12 of the DPCLS Function Pointer patchset, as has been
>>> presented at OVS Conf in Nov '18, and discussed on the ML since then.
>>> I'm aware of the soft-freeze for 2.12, I feel this patchset has had
>>> enough reviews/versions/testing to be merged in 2.12.
>>> Harry van Haaren (5):
>>> dpif-netdev: Implement function pointers/subtable
>>> dpif-netdev: Move dpcls lookup structures to .h
>>> dpif-netdev: Split out generic lookup function
>>> dpif-netdev: Refactor generic implementation
>>> dpif-netdev: Add specialized generic scalar functions
>>> NEWS | 4 +
>>> lib/automake.mk | 2 +
>>> lib/dpif-netdev-lookup-generic.c | 290 +++++++++++++++++++++++++++++++
>>> lib/dpif-netdev-private.h | 129 ++++++++++++++
>>> lib/dpif-netdev.c | 197 ++++++++++-----------
>>> 5 files changed, 525 insertions(+), 97 deletions(-)
>>> create mode 100644 lib/dpif-netdev-lookup-generic.c
>>> create mode 100644 lib/dpif-netdev-private.h
>> I performed a few tests with v11 of this patch-set on my usual setup to
>> performance of the new generic (non-optimized) implementation. The result is
>> new generic implementation is ~5% faster for me than current master (it was
>> for optimized lookup functions) which is good.
>> The code looks OK for me in general. I still don't really like the fact that
>> dpcls depends on the internal structure of a flowmap, but we, probably,
>> deal with that while we have a build time assertion. Hope, we'll have some
>> implementation with the same level of performance in the future.
> Thanks for the feedback on performance Ilya - good to see that we're going
> in the right direction performance wise anyway.
> I have one item I'd still like to improve in this patchset, and its regarding
> where the blocks scratch array is being stored. I'll rework and find a better
> solution than the current, and post that as the lucky patchset v13 :)
As an idea, I could suggest DEFINE_STATIC_PER_THREAD_DATA inside the dpif-netdev-lookup-generic.c.
More information about the dev