> Hi Ian,
> 
> It is taking almost a month to integrate this code.
> Anything should be done to expedite it?

Hi Olga,

I realize it has been a month since the last version was submitted, 
unfortunately in terms of resources for reviews and testing the community is 
limited.

I flagged at the community call two weeks ago that there were a number of 
"large" feature patchsets currently on the backlog that could overlap. It was 
my intention to merge the detailed pmd metrics patchset first and then 
prioritize the HWOL series. There was no arguments raised against this approach.

The detailed PMD metrics was merged last week and HWOL is the feature I will 
look to upstream next.

In terms of expediting it, if the HWOL series could be rebased to head of 
master this week that would help, I can do final validation and have it as part 
of the next pull request (this is aimed for the end of next week).

Thanks
Ian

> 
> Best regards,
> Olga
> 
> -----Original Message-----
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Stokes, Ian
> Sent: Thursday, May 10, 2018 10:19 PM
> To: Shahaf Shuler <shah...@mellanox.com>; f...@napatech.com
> Cc: ovs-dev@openvswitch.org; Flavio Leitner <f...@redhat.com>;
> simon.hor...@netronome.com
> Subject: Re: [ovs-dev] [PATCH v9 0/7] OVS-DPDK flow offload with rte_flow
> 
> 
> 
> > -----Original Message-----
> > From: Shahaf Shuler [mailto:shah...@mellanox.com]
> > Sent: Thursday, May 10, 2018 1:41 PM
> > To: Stokes, Ian <ian.sto...@intel.com>; f...@napatech.com
> > Cc: ovs-dev@openvswitch.org; simon.hor...@netronome.com; Flavio
> > Leitner <f...@redhat.com>
> > Subject: RE: [PATCH v9 0/7] OVS-DPDK flow offload with rte_flow
> >
> > Hi,
> >
> > Friday, April 20, 2018 11:07 AM, Stokes, Ian:
> > > Subject: RE: [PATCH v9 0/7] OVS-DPDK flow offload with rte_flow
> > >
> > > > > Hi,
> > > > >
> > > > > Here is a joint work from Mellanox and Napatech, to enable the
> > > > > flow hw offload with the DPDK generic flow interface (rte_flow).
> > > >
> > > > Hi folks, I feel Mellanox/Netronome have reached the point where
> > > > HWOL can be introduced to OVS DPDK pending performance review.
> > >
> > > Apologies , Mellanox an Napatech.
> >
> > Any progress with this series?
> >
> 
> Hi Shahaf,
> 
> I'm finishing the pull request for this week now. This series is my
> priority in the next pull request.
> 
> The only outstanding item I need to do is a performance check before and
> after to ensure there is no negative impact on the non HWOL usecase. Other
> than that it should be ok.
> 
> Thanks
> Ian
> >
> > >
> > > Ian
> > > >
> > > > This has not been an easy path, but I will put one final request
> > > > out there for comments.
> > > >
> > > > If there are none then pending on Travis compilation and final
> > > > performance checks I'm thinking of introducing this to the code
> base.
> > > >
> > > > Keep in mind this feature is experimental, not only can it be
> > > > changed but it can also be removed pending future review if not
> > maintained.
> > > >
> > > > I invite all to give opinions here as I think this is an important
> > > > feature.
> > > >
> > > > Sincere thanks to all involved.
> > > >
> > > > Regards
> > > > Ian
> > > >
> > > >
> > > > >
> > > > > The basic idea is to associate the flow with a mark id (a
> > > > > unit32_t number).
> > > > > Later, we then get the flow directly from the mark id, which
> > > > > could bypass some heavy CPU operations, including but not
> > > > > limiting to mini flow extract, emc lookup, dpcls lookup, etc.
> > > > >
> > > > > The association is done with CMAP in patch 1. The CPU workload
> > > > > bypassing is done in patch 2. The flow offload is done in patch
> > > > > 3, which mainly does two things:
> > > > >
> > > > > - translate the ovs match to DPDK rte flow patterns
> > > > > - bind those patterns with a RSS + MARK action.
> > > > >
> > > > > Patch 5 makes the offload work happen in another thread, for
> > > > > leaving the datapath as light as possible.
> > > > >
> > > > > A PHY-PHY forwarding with 1000 mega flows (udp,tp_src=1000-1999)
> > > > > and
> > > > > 1 million streams (tp_src=1000-1999, tp_dst=2000-2999) show more
> > > > > than 260% performance boost.
> > > > >
> > > > > Note that it's disabled by default, which can be enabled by:
> > > > >
> > > > >     $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
> > > > >
> > > > > v9: - introduced IP packet sanity checks in a seperate commit
> > > > >     - moved structs and enums definition to the begining of the
> file
> > > > >     - fixed sparse compilation error (error is assumed to be
> > > > > fixed,
> > > > issues
> > > > >       on Travis CI preventing from fully testing it.
> > > > >
> > > > > v8: - enhanced documentation with more details on supported
> > protocols
> > > > >     - fixed VLOG to start with capital letter
> > > > >     - fixed compilation issues
> > > > >     - fixed coding style
> > > > >     - addressed the rest of Ian's comments
> > > > >
> > > > > v7: - fixed wrong hash for mark_to_flow that has been refactored
> > > > > in
> > v6
> > > > >     - set the rss_conf for rss action to NULL, to workaround a
> > > > > mlx5
> > > > change
> > > > >       in DPDK v17.11. Note that it will obey the rss settings
> > > > > OVS-DPDK
> > > > has
> > > > >       set in the beginning. Thus, nothing should be effected.
> > > > >
> > > > > v6: - fixed a sparse warning
> > > > >     - added documentation
> > > > >     - used hash_int to compute mark to flow hash
> > > > >     - added more comments
> > > > >     - added lock for pot lookup
> > > > >     - rebased on top of the latest code
> > > > >
> > > > > v5: - fixed an issue that it took too long if we do flow
> add/remove
> > > > >       repeatedly.
> > > > >     - removed an unused mutex lock
> > > > >     - turned most of the log level to DBG
> > > > >     - rebased on top of the latest code
> > > > >
> > > > > v4: - use RSS action instead of QUEUE action with MARK
> > > > >     - make it work with multiple queue (see patch 1)
> > > > >     - rebased on top of latest code
> > > > >
> > > > > v3: - The mark and id association is done with array instead of
> > CMAP.
> > > > >     - Added a thread to do hw offload operations
> > > > >     - Removed macros completely
> > > > >     - dropped the patch to set FDIR_CONF, which is a workround
> some
> > > > >       Intel NICs.
> > > > >     - Added a debug patch to show all flow patterns we have
> created.
> > > > >     - Misc fixes
> > > > >
> > > > > v2: - workaround the queue action issue
> > > > >     - fixed the tcp_flags being skipped issue, which also fixed
> the
> > > > >       build warnings
> > > > >     - fixed l2 patterns for Intel nic
> > > > >     - Converted some macros to functions
> > > > >     - did not hardcode the max number of flow/action
> > > > >     - rebased on top of the latest code
> > > > >
> > > > > Thanks.
> > > > >
> > > > > ---
> > > > >
> > > > > Finn Christensen (1):
> > > > >   netdev-dpdk: implement flow offload with rte flow
> > > > >
> > > > > Yuanhan Liu (6):
> > > > >   dpif-netdev: associate flow with a mark id
> > > > >   flow: Introduce IP packet sanity checks
> > > > >   dpif-netdev: retrieve flow directly from the flow mark
> > > > >   netdev-dpdk: add debug for rte flow patterns
> > > > >   dpif-netdev: do hw flow offload in a thread
> > > > >   Documentation: document ovs-dpdk flow offload
> > > > >
> > > > >  Documentation/howto/dpdk.rst |  22 ++
> > > > >  NEWS                         |   3 +-
> > > > >  lib/dp-packet.h              |  13 +
> > > > >  lib/dpif-netdev.c            | 497 ++++++++++++++++++++++++-
> > > > >  lib/flow.c                   | 155 ++++++--
> > > > >  lib/flow.h                   |   1 +
> > > > >  lib/netdev-dpdk.c            | 740
> > > > +++++++++++++++++++++++++++++++++++++-
> > > > >  lib/netdev.h                 |   6 +
> > > > >  8 files changed, 1397 insertions(+), 40 deletions(-)
> > > > >
> > > > > --
> > > > > 2.7.4
> > > >
> > > > _______________________________________________
> > > > dev mailing list
> > > > d...@openvswitch.org
> > > >
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm
> > > a
> > > i
> > > > l.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-
> > > dev&data=02%7C01%7Cshahaf
> > > >
> > > s%40mellanox.com%7C59b2f2418c794d93ba9908d5a695aa3d%7Ca652971c7d
> > > 2e4d9b
> > > >
> > > a6a4d149256f461b%7C0%7C0%7C636598084097138936&sdata=JEcbQBd1CfpT
> > > H9xXyP
> > > > VyRkjauq6I0vBavdGmFvAaNU4%3D&reserved=0
> _______________________________________________
> dev mailing list
> d...@openvswitch.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.op
> envswitch.org%2Fmailman%2Flistinfo%2Fovs-
> dev&data=02%7C01%7Colgas%40mellanox.com%7Ca72ca9352fd0441d5f0208d5b6aaecff
> %7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636615767607741769&sdata=jDz
> mtSFd9pLqk%2Bc4rAgmOO%2FyPfCAHaqmYiUF6ahn0j8%3D&reserved=0
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to