[ovs-dev] OVS dpdk-latest branch & UNH testing

Ilya Maximets i.maximets at samsung.com
Mon Apr 29 08:49:31 UTC 2019


On 25.04.2019 13:21, Ian Stokes wrote:
> Hi All,
> 
> At last weeks OVS community call [1] the topic of the UNH DPDK lab testing OVS was raised, specifically the issue of the target branches being used so I wanted to kick off a wider discussion on the ML.
> 
> Currently the UNH Lab tests target the DPDK master branch and the dpdk-latest branch in the OVS repo.
> 
> To date, we've maintained the dpdk-latest branch by merging OVS master every few weeks and applying any required patches to ensure compilation & existing feature functionality with DPDK master branch at that time.
> 
> A concern from UNH is that this introduces 2 moving targets i.e. breakages could be introduced either by commits on DPDK master or a commit merged from OVS master into dpdk-latest.
> 
> From a UNH perspective, it was suggested that it would be easier if the dpdk-latest branch did not have regular  merges from OVS master. Only patches that enable DPDK master compilation and functionality would be committed to dpdk-latest.
> 
> This does reduce the scope of introducing breakage as now breakage should only occur due to a change in DPDK master.
> 
> However the advantage of keeping dpdk-latest in sync with both DPDK master and OVS master is that there is better visibility WRT to changes required in OVS master when it eventually transitions to the latest DPDK LTS release. IMO, this process has worked well for the OVS community since being introduced.
> 
> I would prefer to keep the current process for dpdk-latest, my thinking here is that before pushing the latest merge of OVS master to dpdk-latest it should undergo validation testing anyhow (travis, unit tests, basic p2p  & pvp). If these are passing before the changes are pushed then I would think it there would be minimal danger at least WRT OVS code base changes breaking the UNH tests.
> 
> Another proposal suggested was that another branch could be introduced in the OVS repo specifically to enable UNH OVS DPDK testing. I'm not a fan of this however, I think it's adding overhead to avoid an issue (OVS master merge causing dpdk-latest breakage) that should be addressed regardless if it occurs.
> 
> What are peoples thoughts?

Hi.

I'd also prefer "current" model but with a few changes. I'm suggesting
a periodic 'git pull --rebase' from master to dpdk-latest instead of merge.
'dpdk-latest' branch is not a stable branch and I don't think that anyone
should use it on a regular basis. So it should be expected that this branch
could be rebased at any time. This should not produce any issues for CI
systems as they are commonly clones entire repo or checkouts branch to the
new local branch. This way DPDK lab will test dpdk commits over the current
'dpdk-latest' branch of OVS which will be periodically moved to match with
latest OVS master. Of course, the branch should be validated by Travis or
local build before the force-push to avoid DPDK Lab test failures caused by
OVS. We need to update the travis scripts on this branch to build with
DPDK master.

Rebasing produces exactly same number of conflicts as merging, however it
keeps the history clean and readable. Current merge strategy only
complicates the history making it impossible to say what commits are differ.
And also in addition to resolving merge conflicts we'll have to resolve same
conflicts again while pulling changes back to master while moving to next
DPDK LTS.

---

I have one important question: What we're trying to test?
1. Does it check that OVS builds with new DPDK?
2. Or it tests the OVS performance with new DPDK?
3. Or it tests DPDK patches that they doesn't break the API currently used by OVS?
4. Or it tests the performance of new OVS patches?

The target of 1 could be achieved by the Travis build in OVS repo.
The target of 2 does not have much in common with OVS. Achieved by simple DPDK
performance tests already existed on lab.dpdk.org.
The target of 3 makes no much sense because we need to fix OVS, not the DPDK.
Covered by the target of question 1.
The target of 4 is probably the most interesting, however it's not the case
of building with latest DPDK master. This should be done by testing current
OVS master with stable DPDK.

So, what is the goal of this testing? I'm asking because there is no any
information available here of on lab.dpdk.org.

Best regards, Ilya Maximets.


More information about the dev mailing list