29/04/2019 10:49, Ilya Maximets: > 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?
Yes > 2. Or it tests the OVS performance with new DPDK? It would be more about DPDK perf tested with OVS. > 3. Or it tests DPDK patches that they doesn't break the API currently used by > OVS? Yes > 4. Or it tests the performance of new OVS patches? No, the DPDK lab is more interested in DPDK behaviour and perf. > 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. Perf variations may be different in the OVS scenario. > The target of 3 makes no much sense because we need to fix OVS, not the DPDK. It allows to check that the behaviour (part of API) is not broken. > 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. Yes I agree. > So, what is the goal of this testing? I'm asking because there is no any > information available here of on lab.dpdk.org. We agreed to use OVS as an interesting use case of DPDK. The main purpose is to test DPDK, so the moving target should be DPDK. However, you need to update OVS from time to time, so I think a rebase may be acceptable when you are sure it is well validated in advance, maybe roughly monthly? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
