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. 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
