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

[Ilya Maximets]

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