[ovs-dev] [PATCH v2 2/2] travis: Make it possible to build against a dpdk branch.

Stokes, Ian ian.stokes at intel.com
Thu Jun 20 16:20:55 UTC 2019


> > On 20.06.2019 15:10, Ilya Maximets wrote:
> > > On 20.06.2019 14:56, Stokes, Ian wrote:
> > >>>> -----Original Message-----
> > >>>> From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-
> > >>>> bounces at openvswitch.org] On Behalf Of Stokes, Ian
> > >>>> Sent: Thursday, June 20, 2019 11:53 AM
> > >>>> To: Ilya Maximets <i.maximets at samsung.com>; David Marchand
> > >>>> <david.marchand at redhat.com>
> > >>>> Cc: ovs dev <dev at openvswitch.org>
> > >>>> 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
> > >>> <i.maximets at samsung.com
> > >>>>> <mailto:i.maximets at samsung.com>> 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 <david.marchand at redhat.com
> > >>>>> <mailto:david.marchand at redhat.com>>
> > >>>>>>     > ---
> > >>>>>>     > 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.

Tests came back ok so I've pushed the rebase to dpdk-latest branch. Thasnk for the help here.

I assume we want the same for dpdk-hwol, except in this case we rebase from dpdk-latest (after dpdk-latest has just been rebased to master and pushed).

Ian



More information about the dev mailing list