> On 20.06.2019 15:10, Ilya Maximets wrote: > > On 20.06.2019 14:56, Stokes, Ian wrote: > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:ovs-dev- > >>>> [email protected]] On Behalf Of Stokes, Ian > >>>> Sent: Thursday, June 20, 2019 11:53 AM > >>>> To: Ilya Maximets <[email protected]>; David Marchand > >>>> <[email protected]> > >>>> Cc: ovs dev <[email protected]> > >>>> Subject: Re: [ovs-dev] [PATCH v2 2/2] travis: Make it possible to > build > >>>> against a dpdk branch. > >>>> > >>>>> On 19.06.2019 14:35, David Marchand wrote: > >>>>>> > >>>>>> > >>>>>> On Wed, Jun 19, 2019 at 1:22 PM Ilya Maximets > >>> <[email protected] > >>>>> <mailto:[email protected]>> wrote: > >>>>>> > >>>>>> On 19.06.2019 10:26, David Marchand wrote: > >>>>>> > Rework the build script so that we can pass branches and > tags. > >>>>>> > > >>>>>> > With this, DPDK_VER can be passed as: > >>>>>> > - a string starting with refs/ which is understood as a git > >>>>> reference. > >>>>>> > This triggers a git clone on DPDK_GIT (default value points > >>> to > >>>>>> > https://dpdk.org/git/dpdk) for a single branch pointing to > >>>> this > >>>>>> > reference (to save some disk), > >>>>>> > - else, any other string which is understood as an official > >>>>> release. > >>>>>> > This triggers a tarball download on dpdk.org > >>>> <http://dpdk.org>. > >>>>>> > > >>>>>> > Signed-off-by: David Marchand <[email protected] > >>>>> <mailto:[email protected]>> > >>>>>> > --- > >>>>>> > Changelog since v1: > >>>>>> > - removed (now unneeded) directory renames > >>>>>> > - added a "git log" so that we have the current git revision > >>> in > >>>>> the logs > >>>>>> > > >>>>>> > --- > >>>>>> > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> I tested this patch with: > >>>>>> > >>>>>> - DPDK=1 DPDK_GIT="https://dpdk.org/git/dpdk-stable"; > >>>>> DPDK_VER="refs/heads/18.11" > >>>>>> > >>>>>> and > >>>>>> > >>>>>> - DPDK=1 DPDK_VER="refs/heads/master" > >>>>>> > >>>>>> Works fine. > >>>>>> > >>>>>> > >>>>>> Thanks Ilya. > >>>>>> > >>>>>> I could have detailed my non-reg tests: > >>>>>> - DPDK=1 > >>>>>> - DPDK=1 DPDK_VER=18.11.2 > >>>>>> - DPDK=1 DPDK_VER=refs/tags/v18.11.2 > >>>> DPDK_GIT=http://dpdk.org/git/dpdk- > >>>>> stable > >>>>>> - DPDK=1 DPDK_VER=refs/heads/18.11 > >>> DPDK_GIT=http://dpdk.org/git/dpdk- > >>>>> stable > >>>>>> > >>>>>> > >>>>>> > >>>>>> So, I pushed this and the previous patch to master. > >>>>>> > >>>>>> > >>>>>> Cool, so I suppose you will handle the changes on dpdk-latest, > >>> right? > >>>>> > >>>>> Not sure. Ian managed these branches (hwol, latest) previously. > >>>>> > >>>>> Ian, will you rebase dpdk-latest onto current master? > >>>> > >>>> Yes, I'll look at this today. I know when I look last week there were > a > >>>> few conflicts to be resolved. So will sort these. > >>> > >>> Hi Ilya, just started looking at this again, are yu sure it's a rebase > we > >>> want here i.e. rebase dpdk-latest on master? > >>> > >>> Essentially we what I'm seeing is as the dpdk-latest changes are being > >>> applied ontop of the least master history all the previous changes in > >>> dpdk-latest have to re-applied include changes such as upgrade to > 18.08 > >>> etc. it's just making it a bit messy, especially with some of the HOWL > >>> changes we've had on master. > > > > > > Actually, these patches: > > > > 7f021f902bb3 ("netdev-dpdk: Upgrade to dpdk v18.08") > > 270d9216f1ed ("netdev-dpdk: Set scatter based on capabilities") > > bef2cdc8f412 ("netdev-dpdk: Fix returning the field of malloced > struct.") > > 73c1a65167fc ("redhat: change variable used for non-root user > support") > > eb485f60ce44 ("dpdk: Update to use DPDK 18.11.") > > > > was already incorporated into: > > > > 03f3f9c0faf8 ("dpdk: Update to use DPDK 18.11.") > > > > So, could be just skipped while rebasing. > > IIUC, in the end there should be only 2 patches on top of master. > > One for meter color and one for rte_ prefix. > >
Ya, good point, I'm doing that right now and comes across cleaner (at least from commits we're not moving from 18.11.1 to 18.08 etc, which doesn’t look right). > >>> > >>> I'm also think would it not require a force push to the dpdk-latest > >>> branch? The re-write of the commit history will change etc. > > > > Yes, this will require the force-push. > > Ok, I think this is ok if others are ok with it? I think it's worth it. > >>> > >>> I know the merge process wasn't ideal from a commit history POV but it > did > >>> avoid issues such as this in the past. What are your thoughts? > >> > >> To provide a better example, what I mean would be if you look at the > commit for moving to 18.11 on master, in the commit message we actually > use commit IDs form commits to dpdk-latest to reference and help accredit > the authorship of work. If we rebase dpdk-latest with master, these commit > ID's change in the dpdk-latest branch, meaning in master we have incorrect > commit ID etc. in the commit message. > >> > >> I guess that’s what I was trying to avoid with the rebase approach and > hence why I had used the merge approach (similar to how we used to use > dpdk-merge branches). > >> > >> Do you have a way around this? > > > > As David suggested we may tag current branch before rebase to not loose > > the hashes. However, there was a simple squash of these commits and > there > > was no important information we could loose. For the future, we could > > avoid such issues by using more permanent pointers like mail- > list/patchwork > > links instead of git hashes from different/unreliable branches. > > > > To be clear, I think that having cross-branch pointers in a git repo is a > bad practice. > I agree, in hindsight it would have been better to use maillist. Live and learn :). I'm just running some smoke tests now on the rebase to make sure all is fucntions as expected with dpdk master, if it's all ok I'll push this evening. Ian > >> > >> Thanks > >> Ian > >>> > >>> Ian > >>>> > >>>> Thanks > >>>> Ian > >>>> > >>>>> > >>>>> Best regards, Ilya Maximets. > >>>> _______________________________________________ > >>>> dev mailing list > >>>> [email protected] > >>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
