qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 00/17] Net patches


From: Daniel P . Berrangé
Subject: Re: [PULL 00/17] Net patches
Date: Thu, 14 Sep 2023 09:13:04 +0100
User-agent: Mutt/2.2.9 (2022-11-12)

On Wed, Sep 13, 2023 at 08:46:42PM +0200, Ilya Maximets wrote:
> On 9/8/23 16:15, Daniel P. Berrangé wrote:
> > On Fri, Sep 08, 2023 at 04:06:35PM +0200, Ilya Maximets wrote:
> >> On 9/8/23 14:15, Daniel P. Berrangé wrote:
> >>> On Fri, Sep 08, 2023 at 02:00:47PM +0200, Ilya Maximets wrote:
> >>>> On 9/8/23 13:49, Daniel P. Berrangé wrote:
> >>>>> On Fri, Sep 08, 2023 at 01:34:54PM +0200, Ilya Maximets wrote:
> >>>>>> On 9/8/23 13:19, Stefan Hajnoczi wrote:
> >>>>>>> Hi Ilya and Jason,
> >>>>>>> There is a CI failure related to a missing Debian libxdp-dev package:
> >>>>>>> https://gitlab.com/qemu-project/qemu/-/jobs/5046139967
> >>>>>>>
> >>>>>>> I think the issue is that the debian-amd64 container image that QEMU
> >>>>>>> uses for testing is based on Debian 11 ("bullseye" aka "oldstable")
> >>>>>>> and libxdp is not available on that release:
> >>>>>>> https://packages.debian.org/search?keywords=libxdp&searchon=names&suite=oldstable&section=all
> >>>>>>
> >>>>>> Hmm.  Sorry about that.
> >>>>>>
> >>>>>>>
> >>>>>>> If we need to support Debian 11 CI then either XDP could be disabled
> >>>>>>> for that distro or libxdp could be compiled from source.
> >>>>>>
> >>>>>> I'd suggest we just remove the attempt to install the package for now,
> >>>>>> building libxdp from sources may be a little painful to maintain.
> >>>>>>
> >>>>>> Can be re-added later once distributions with libxdp 1.4+ will be more
> >>>>>> widely available, i.e. when fedora dockerfile will be updated to 39,
> >>>>>> for example.  That should be soon-ish, right?
> >>>>>
> >>>>> If you follow the process in docs/devel/testing.rst for adding
> >>>>> libxdp in libvirt-ci, then lcitool will "do the right thing"
> >>>>> when we move the auto-generated dockerfiles to new distro versions.
> >>>>
> >>>> Thanks!  I'll prepare changes for libvirt-ci.
> >>>>
> >>>> In the meantime, none of the currently tested images will have a required
> >>>> version of libxdp anyway, so I'm suggesting to just drop this one 
> >>>> dockerfile
> >>>> modification from the patch.  What do you think?
> >>>
> >>> Sure, if none of the distros have it, then lcitool won't emit the
> >>> dockerfile changes until we update the inherited distro version.
> >>> So it is sufficient to just update libvirt-ci.git with the mappings.yml
> >>> info for libxdp, and add 'libxdp' to the tests/lcitool/projects/qemu.yml
> >>> file in qemu.git. It will then 'just work' when someone updates the
> >>> distro versions later.
> >>
> >> I posted an MR for libvirt-ci adding libxdp:
> >>   https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/429
> >>
> >> Please, take a look.
> >>
> >> The docs say that CI will try to build containers with the MR changes,
> >> but I don't think anything except sanity checks is actually tested on MR.
> >> Sorry if I missed something, never used GitLab pipelines before.
> > 
> > No, that's our fault - we've broken the CI and your change alerted
> > me to that fact :-)
> > 
> >> Note that with this update we will be installing older version of libxdp
> >> in many containers, even though they will not be used by QEMU, unless
> >> they are newer than 1.4.0.
> > 
> > No problem, as it means QEMU CI will demonstrate the the meson.build
> > change is ignoring the outdatd libxdp.
> > 
> >> tests/lcitool/projects/qemu.yml in qemu.git cannot be updated without
> >> updating a submodule after the MR merge.
> > 
> > Yep.
> 
> Since all the required changes went into libvirt-ci project, I posted an
> updated patch set named:
> 
>   '[PATCH v4 0/2] net: add initial support for AF_XDP network backend'
> 
> Please, take a look.
> 
> This should fix the CI issues, though I'm not sure how to run QEMU gitlab
> pipelines myself, so I didn't actually test all the images.

  git push gitlab  -o ci.variable=QEMU_CI=2

will create pipeline and immediately run all jobs.

Replace 'gitlab' with the name of the git remote pointing to your
gitlab fork of QEMU.

Using QEMU_CI=1 will create pipeline, but let you manually start
individual jobs from the web UI.

For further details see docs/devel/ci-jobs.rst.inc


> 
> Sent as a patch set because the libvirt-ci submodule bump brings in a few
> unrelated changes.  So, I split that into a separate patch.

Yep, that's perfect thanks.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]