On 11.06.2019 19:10, David Marchand wrote: > > > On Tue, Jun 11, 2019 at 5:36 PM Ilya Maximets <i.maxim...@samsung.com > <mailto:i.maxim...@samsung.com>> wrote: > > On 11.06.2019 18:21, Ian Stokes wrote: > > On 6/11/2019 3:40 PM, Aaron Conole wrote: > >> Ian Stokes <ian.sto...@intel.com <mailto:ian.sto...@intel.com>> writes: > >> > >>> On 6/10/2019 3:57 PM, Ian Stokes wrote: > >>>> On 6/6/2019 12:36 PM, David Marchand wrote: > >>>>> > >>>>> > >>>>> On Thu, Jun 6, 2019 at 1:25 PM Ian Stokes <ian.sto...@intel.com > <mailto:ian.sto...@intel.com> > >>>>> <mailto:ian.sto...@intel.com <mailto:ian.sto...@intel.com>>> wrote: > >>>>> > >>>>> On 6/4/2019 12:14 PM, David Marchand wrote: > >>>>> > On Tue, Jun 4, 2019 at 11:29 AM David Marchand > >>>>> > <david.march...@redhat.com > <mailto:david.march...@redhat.com> <mailto:david.march...@redhat.com > <mailto:david.march...@redhat.com>> > >>>>> <mailto:david.march...@redhat.com > <mailto:david.march...@redhat.com> > >>>>> <mailto:david.march...@redhat.com > <mailto:david.march...@redhat.com>>>> wrote: > >>>>> > > >>>>> > Following a rework of dpdk network structures names [1], > >>>>> update the > >>>>> > concerned parts. > >>>>> > > >>>>> > Ran Olivier script: > >>>>> > sh prefix-net-rte.sh $(find -name "*dpdk*.c") > >>>>> > sh prefix-net-rte.sh $(find -name "*dpdk*.h") > >>>>> > sh prefix-net-rte.sh $(find -name "*rte*.c") > >>>>> > sh prefix-net-rte.sh $(find -name "*rte*.h") > >>>>> > > >>>>> > Plus an extra pass following further changes [2]: > >>>>> > old=RTE_IPv4 > >>>>> > new=RTE_IPV4 > >>>>> > git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g" > >>>>> > > >>>>> > old=RTE_ETHER_TYPE_IPv4 > >>>>> > new=RTE_ETHER_TYPE_IPV4 > >>>>> > git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g" > >>>>> > > >>>>> > old=RTE_ETHER_TYPE_IPv6 > >>>>> > new=RTE_ETHER_TYPE_IPV6 > >>>>> > git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g" > >>>>> > > >>>>> > 1: > http://mails.dpdk.org/archives/dev/2019-May/132612.html > >>>>> > 2: https://git.dpdk.org/dpdk/commit/?id=0c9da7555da8 > >>>>> > > >>>>> > > >>>>> > Olivier noticed that I had used an early version of his > patch. > >>>>> > The published one handles the update on RTE_IPv4. > >>>>> > I tried the last version which gives the same result anyway. > >>>>> > So the extra pass is unnecessary. > >>>>> > > >>>>> > I can send a v2 to update the commitlog accordingly. > >>>>> > > >>>>> > >>>>> Hi David, > >>>>> > >>>>> thanks for this, upon inspection the patch looks fine and I can > >>>>> confirm > >>>>> that dpdk-latest is now building with Master of DPDK again. > >>>>> > >>>>> I'm just in the process of running a few smoke tests to make > sure > >>>>> there's no issues functionally (I don't expect to see any as > the > >>>>> changes > >>>>> seem straight forward). > >>>>> > >>>>> WRT the v2, what exactly do you want to change in the commit? > If it's > >>>>> trivial I can amend it before committing. > >>>>> > >>>>> > >>>>> > >>>>> I just stripped the useless part in the commitlog and put a link to > >>>>> Olivier mail which contained his script. > >>>>> You can see the commitlog here: > >>>>> > https://github.com/david-marchand/ovs/commit/9d367de7d323c28f7c89d590ff60373c47ffa073 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> I'll be applying this to dpdk-latest and dpdk-hwol branches but > >>>>> not ovs > >>>>> master (master is still using DPDK 18.11.1 currently so no > need for > >>>>> these changes until it moves to 19.11). > >>>>> > >>>>> > >>>>> > >>>>> Yes, makes sense. > >>>>> Thanks Ian. > >>>> > >>>> Thanks David, validated and pushed to dpdk-latest and dpdk-wol. > >>> > >>> Good catch actually. In the past we had previously tracked the latest > >>> DPDK release to compile against, but now that dpdk-latest is used with > >>> the UNH DPDK CI it probably makes more sense to track DPDK master at > >>> that's what dpdk-latest looks to enable compilation of. > >>> > >>> I'm not against this, would be interested in what peoples thoughts are > >>> and if so we can modify travis for the dpdk-latest branch. > >> > >> At least for this part (per-branch), the travis yml is read on a > >> per-branch basis. If it changes on one branch, only that branch will > >> be affected. Is this what you mean? > > > > Yes, travis would be changed to track master just for dpdk-latest is my > understanding. OVS master and OVS release branches should still only track > the DPDK LTS release they are currently validated against in their travis yml. > > Makes sense. Broken travis builds on dpdk-latest branch are annoying. > > > I have changes that apply to both master and dpdk-latest branch, then a > change for the switch to dpdk master branch in dpdk-latest. > > I can post the changes for master on top of your patch that disables > kni/igb_uio. > We merge yours and mine in master, then pull master into dpdk-latest. > > Then I would only send the switch to dpdk master branch for the dpdk-latest > ovs branch. > > Is this ok this way ?
OK for me in general. However, I think that it's time for 'git pull --rebase' on dpdk-latest branch since it's already a bit diverged and some patches, including travis patches, will have conflicts. So, I agree with your scheme, but with rebase instead of pull. BTW, I'm leaving the office now and will back only on Monday due to public holidays and a small PTO. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev