[ovs-dev] [RFC PATCH 0/8] dpif-netdev: Refactor cycle count and rebased patches

[Stokes, Ian]

> On 01/10/2018 08:14 AM, 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.
> >
> > BR, Jan
> 
> Hi Jan/all - I just sent a new version of the balance stats (3b) in reply
> to the original series. I liked that it was being simplified to not count
> the rxq idle cycles in the merged series version but there was still a lot
> of code for storage/calculations of % of pmd in the rxqs. It got me
> thinking that it could be simplified a lot more by moving these directly
> to the pmd, so I did that.
> 
> I think it is now pretty independent of the other patch sets that are
> being developed around the pmd, so there should be no dependency issues.
> Probably at most a trivial rebase if other patches got merged before or
> after it.

+1, I think this set looks fairly independent now, I'll have some spare cycles this evening to take a look.

Ian
> 
> thanks,
> Kevin.
> 
> >
> >> -----Original Message-----
> >> From: ovs-dev-bounces at openvswitch.org
> >> [mailto:ovs-dev-bounces at openvswitch.org] On Behalf Of Jan Scheurich
> >> Sent: Tuesday, 09 January, 2018 14:58
> >> To: Kevin Traynor <ktraynor at redhat.com>; Ilya Maximets
> >> <i.maximets at samsung.com>; Stokes, Ian <ian.stokes at intel.com>
> >> Cc: dev at openvswitch.org
> >> 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
> >> dev at openvswitch.org
> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev