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

[Van Haaren, Harry]

> -----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 :)

Cheers, -Harry