[ovs-dev] OVS DPDK Latest & HWOL Branches

[Kevin Traynor]

On 08/30/2018 03:34 PM, Ian Stokes wrote:
> On 8/30/2018 2:51 PM, Ophir Munk wrote:
>> Hi Ian,
>> Please find comments inline.
>>
>>> -----Original Message-----
>>> From: Ian Stokes [mailto:ian.stokes at intel.com]
>>> Sent: Thursday, August 30, 2018 1:15 PM
>>> To: ovs-dev at openvswitch.org
>>> Cc: Ophir Munk <ophirmu at mellanox.com>; Ben Pfaff <blp at ovn.org>; Aaron
>>> Conole <aconole at redhat.com>; Kevin Traynor <ktraynor at redhat.com>
>>> Subject: Re: [ovs-dev] OVS DPDK Latest & HWOL Branches
>>>
>>> On 8/30/2018 9:31 AM, Stokes, Ian wrote:
>>>>> On Tue, Aug 28, 2018 at 11:32:31AM +0100, Ian Stokes wrote:
>>>>>> On 8/27/2018 5:16 PM, Ben Pfaff wrote:
>>>>>>> On Mon, Aug 27, 2018 at 04:05:39PM +0000, Ophir Munk wrote:
>>>>>>>> 4. How can I inspect the new branches? Currently I am not seeing
>>> them.
>>>>>>>
>>>>>>> I do not think that Ian has created the new branches yet.
>>>>>>
>>>>>> I can create these today.
>>>>>>
>>>>>> There was some discussion as regards the branch names. Before
>>>>>> creating them are people happy with 'branch-dpdk-latest' and 'branch-
>>> dpdk-hwol' ?
>>>>>>
>>>>>> If there are no objections then I'll go ahead with these today.
>>>>>
>>>>> I'd leave out the "branch-" prefixes.  The existing branches only
>>>>> have those prefixes because e.g. "2.10" seemed too easy to confuse
>>>>> with a release name.
>>>>
>>>> OK, that makes sense, we'll stick with 'dpdk-latest' and 'dpdk-hwol'
>>>> so.
>>>>
>>>
>>> Just a quick follow up. I've push 'dpdk-latest' and 'dpdk-hwol'
>>> branches to the
>>> OVS repo so people can start using them.
>>>
>>
>> I confirm fetching the new branches
> 
> Thanks for testing and confirming.
>>
>>> If sending patches user the subject header prefix 'dpdk-latest' or
>>> 'dpdk-hwol'
>>> so that it's clear which branch the patch is intended for.
>>>
>>> We should document the usage of these branches to make it clear they are
>>> intended to aid development work only, not a replacement for master so
>>> that casual users do not get confused. I'll look into this.
>>>
>>> There are still a few questions we should nail down:
>>>
>>> How often should dpdk-latest rebase to pull changes from master?
>>> Weekly/biweekly?
>>>
>>> How often should dpdk-hwol rebase to pull changes form dpdk-latest?
>>>
>>
>> Both branches should be rebased as frequently as possible and
>> simultaneously.
>> A weekly rebase seems OK.
>> Important: is there an option to run regression tests on these
>> branches (verifying backward compatibility)?
> 
> Both branches will automatically be run through the OVS travis build
> when a new commit is made, I've tested this already today after creating
> them and can confirm they are working, links below to the build output.
> 
> dpdk-latest: https://travis-ci.org/openvswitch/ovs/builds/422471470
> dpdk-hwol: https://travis-ci.org/openvswitch/ovs/builds/422472112
> 
> On my side as the committer for the branches I plan to run any patches
> through the vsperf performance and integration tests also to check for
> any performance degradation or breaks in existing features.
> 

Weekly or bi-weekly seems like a good base plan. You might decide to
tweak it when it starts, depending what has changed on master and how
much effort it's proving to be around testing and if conflicts are
occurring etc.

> Besides these, 0 day robot will help catch issues with patches once they
> are send to the mailing list.
>>
>>> I'd like to hear input from users on these as it would affect their
>>> workflow if
>>> they are active with these branches. If we can stick to a schedule it
>>> should
>>> make life easier.
>>>
>>
>> Who are going to be the new branches maintainers?
>> I am volunteering for being a maintainer.
>> If there is a limitation that only Ian can update the new branches -
>> that's OK.
>> In that case Ian can pull them from a known remote repository handled
>> by the maintainers
> 
> I'm not sure of the model you are looking for here. I would have thought
> that patches to be committed to either dpdk-latest or dpdk-hwol would be
> sent to the mailing list as per usual for review from other developers
> in the community. Then applied by the committer to dpdk-latest or
> dpdk-hwol once there is agreement and sign off.
> 

+1 for the standard email workflow and applying directly on the branches
created for this.

> If we are pulling from a remote branch then it would seem to defeat this
> as patches on that branch would have already been merged without
> discussion from the ML?
> 
> Maybe I've misunderstood.
> 
>>
>> One issue not discussed in this thread is the upgrade to dpdk 18.08 on
>> OVS master branch.
>> I suggest dedicating the weeks till end of September for OVS testing
>> by NIC vendors.
> 
> I don't think master will upgrade to 18.08 anymore, instead it would
> wait for 18.11 LTS. I would think having the dpdk-latest branch negates
> the need for OVS master to move to 18.08 now?
> 
> One of the main concerns regarding moving to DPDK 18.08 on master is if
> the situation arose where there was a blocking issue for OVS moving to
> DPDK 18.11. You would then have an OVS release using 18.08 and we wish
> to avoid releases using non DPDK LTS.
> 

+1. The idea of moving master to 18.08 was really as an alternative to
having a dpdk-latest branch, in order to help integration towards 18.11.
It's not helpful now that there is a dedicated branch for that.

>> In parallel dpdk-latest branch should be updated (starting
>> immediately) to support dpdk-18.08 followed by running regression
>> tests on it.
>> We can target end of September for adding all missing code, cleaning
>> Travis errors, replacing deprecated APIs, etc.
>> By end of September Ian should be able to merge dpdk-latest (18.08)
>> into OVS master branch.
>>
> 
> As per above, the next merge of dpdk-latest to OVS master would be the
> move to 18.11.
> 
> Ian
>