[ovs-dev] [PATCH v12 0/5] dpcls func ptrs & optimizations

Ilya Maximets 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.
> 
> <snip>
> 
>>> 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
>> check
>> performance of the new generic (non-optimized) implementation. The result is
>> that
>> new generic implementation is ~5% faster for me than current master (it was
>> 12%
>> 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,
>> could
>> deal with that while we have a build time assertion. Hope, we'll have some
>> better
>> 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 mailing list