On 10.01.2018 11:14, Jan Scheurich wrote: > Hi, > > I have just sent out a series with patches #1 and #2 as agreed. They address > comments by Ilya on #1 and the draft for nestable cycle counters. > > I haven't done extensive tests yet as I wanted to share as early as possible. > I will continue to test and prepare a rebased v6 of the remainder of the PMD > metrics #3c series soon. > > Looking forward to review and test rebased #3a and #3b.
I just rebased time based output batching (3a) on top of '[PATCH v8 0/2] Refactor PMD stats and cycle counting'. New v10 version available here: https://patchwork.ozlabs.org/project/openvswitch/list/?series=22919 v8 of PMD stats refactoring looks close to be ready for merging. Just few more fixes required with arm build and pmd_stats_init. I'll continue to review and test. Best regards, Ilya Maximets. > > BR, Jan > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Jan Scheurich >> Sent: Tuesday, 09 January, 2018 14:58 >> To: Kevin Traynor <[email protected]>; Ilya Maximets >> <[email protected]>; Stokes, Ian <[email protected]> >> Cc: [email protected] >> Subject: Re: [ovs-dev] [RFC PATCH 0/8] dpif-netdev: Refactor cycle count and >> rebased patches >> >>>>>> My suggestion would be to start with the least controversial refactoring >>>>>> first so that we do not introduce complex things in one >> patch >>>>> that we then throw out in the next one again. By that let's try to make >>>>> the actual feature patches as small and independent as >> possible. >>>>>> >>>>>> Here’s my suggestions: >>>>>> 1. dpif-netdev: Refactor PMD performance into dpif-netdev-perf >>>>>> 2. dpif-netdev: Refactor cycle counting (nestable cycle timer) >>>>>> 3a. Time-based tx batching >>>>>> dpif-netdev: Use microsecond granularity. >>>>>> dpif-netdev: Count cycles on per-rxq basis. (using the nestable cycle >>>>>> timers) >>>>>> dpif-netdev: Time based output batching. >>>>>> docs: Describe output packet batching in DPDK guide. >>>>>> NEWS: Mark output packet batching support. >>>>>> 3b. dpif-netdev: Add percentage of pmd/core used by each rxq. >>>>>> 3c. Detailed PMD Performance metrics >>>>>> dpif-netdev: Detailed performance stats for PMDs >>>>>> dpif-netdev: Detection and logging of suspicious PMD iterations >>>>>> >>>>>> What do you think? >>>>> >>>>> Basically, this looks good to me. But I still think that we should work >>>>> on that >>>>> step-by-step not tying to make all the work at once. This will save time >>>>> of >>>>> rebasing on intermediate versions of patches. >>>> >>>> Fine with me as long as that doesn't stop review and testing of the not >>>> yet rebased >>>> patches 3a-c. We need those tests and reviews to find and address any >>>> deficiencies >>>> inherent in the feature (independent from rebasing). >>>> >>> >>> I'm not sure if there is some reason you have tied those patches (3) >>> together. I thought the idea now was to keep things separate? >> >> The idea is to have them as decoupled as possible once the first two >> refactoring patches are in place. Ideally one could apply them in any >> order. At least with much less effort than currently and lots of reverting >> changes. I didn't want to imply any specific order here. >> >>> >>> I'm making a few edits on 3b atm. Can possibly take this out of the >>> chain. It applies without any of the other patches, but I'm not sure if >>> it's functional yet. >> >> It should apply after refactoring patches #1 and #2. Otherwise we will have >> even more work to do the refactoring later. Do you work on >> the simplified version I proposed? >> >>> >>>>> I'll try to spend some time from the rest of today to check out "nestable >>>>> cycle timers". >>>>> Would like to see fixed patch from #1 and a proper patch for #2. >>>> >>>> I will try to send out patches for #1 (v6) and #2 this afternoon. >>>> >>>>> Step #3a should not be hard. >>>>> >>>> >>>> @Ian, Kevin and Billy: Should we anyway have a short Skype chat? >>>> >>> >>> I think we have a plan, let's skip and keep on email. >> >> Fine with me. >> _______________________________________________ >> dev mailing list >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
