From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7DDFAA0C3F for ; Fri, 16 Apr 2021 14:46:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6CB2D141D8E; Fri, 16 Apr 2021 14:46:44 +0200 (CEST) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by mails.dpdk.org (Postfix) with ESMTP id 07145141D82 for ; Fri, 16 Apr 2021 14:46:42 +0200 (CEST) Received: by mail-ej1-f45.google.com with SMTP id w3so41993658ejc.4 for ; Fri, 16 Apr 2021 05:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CanhGKZKyCuJdUjn0s+yfySCHKpnUoh+ErYWXxXO2Dc=; b=UCflie4oOPz7yfg5qGJTf+YlRVbHypfrWG8HgNDyQV/janUKdMmDbfEC9bCacdUXMx Vf90lJEIjQf59fUKSbyYUvVnVU8r7vdmF20HT5PJ6M59xCERRtaRc9Ni+onkgNW1Vw29 LN7ZpybgXOlKIzX2WOG+O/wm/LDmiPs1routY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CanhGKZKyCuJdUjn0s+yfySCHKpnUoh+ErYWXxXO2Dc=; b=UOd/hM7pzfxu3m97lgcwXnzRQM1OG0rT1usJu7BhXTYhnJk/vjeNUhsuhf0UsujjYk OQihmYUTUk5+jakOqyouz+OGcAUTCk3knReyOptJNGqBa/hxkABIGmaiOkiWmqwDw6jB jmWXk7KMcp8EWOIkYmCNU+4vkIICqfnn3AUrDKudaskLoSP0UHOJ6aWlCESUpp5hceb+ Cvj5URABR6HNMiVLSZLg8W3/pzduuGf3cJ3RsBSzF/f4dEvlGfrRkGWrrQcgMYQ6p6iA oP6TGYScCbrtR7hUZY07YqJGhRsKkdG5RtzVCMI3pjKFvkwTDlAY7MsPbWhPYCr3PorA lHPg== X-Gm-Message-State: AOAM532/vUZvi3lNJJcaigkXo4yEl4Kd1Kw2O4u+fzncg1CYoEqmGzgj IqkCz4zi73+fKQmr2o4Jy9CSJilzSWVSnMGM9Ocq1g== X-Google-Smtp-Source: ABdhPJw/388JbyHrI8sbZQYp0r5hEfk/E8V2MmsUee1rglu7VxLF36R+FEg7Mnf6Uz+6Ep++3sEiIdUi2WI40PD4uJU= X-Received: by 2002:a17:906:b156:: with SMTP id bt22mr4117625ejb.181.1618577202506; Fri, 16 Apr 2021 05:46:42 -0700 (PDT) MIME-Version: 1.0 References: <1608304614-13908-2-git-send-email-xuemingl@nvidia.com> <1618283653-16510-1-git-send-email-xuemingl@nvidia.com> <1618283653-16510-2-git-send-email-xuemingl@nvidia.com> In-Reply-To: From: Lincoln Lavoie Date: Fri, 16 Apr 2021 08:43:29 -0400 Message-ID: To: Aaron Conole Cc: David Marchand , dpdklab , Thomas Monjalon , Gaetan Rivet , dev , "Xueming(Steven) Li" , Asaf Penso , Wenzhuo Lu , Beilei Xing , Bernard Iremonger , Gaetan Rivet , Anatoly Burakov , Ray Kinsella , Neil Horman , Ferruh Yigit , Andrew Rybchenko , Dodji Seketeli , ci@dpdk.org, Owen Hilyard Content-Type: multipart/alternative; boundary="0000000000003287ae05c0165f23" Subject: Re: [dpdk-ci] [dpdklab] Re: [dpdk-dev] [PATCH v5 1/5] devargs: unify scratch buffer storage X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org Sender: "ci" --0000000000003287ae05c0165f23 Content-Type: text/plain; charset="UTF-8" All of the UNH ABI testing is moving info containers, so it can be run on top of each OS, alongside the other compile and unit testing. This is actually ready now, but hasn't been pushed live this week, because of the backlog in the system because of the DTS failure. The additional compile jobs are already online now, it's just ABI that hasn't been pushed live. This means the current ABI (what is reporting right now) is running on 18.04 for x86 and 20.04 for aarch64. The aarch64 one will continue forward, because we're not going to moving to emulated environments for testing on that architecture. This has two implications, first, the scripts for running ABI (and the other tests) become part of the container definition, and at the last meeting we talked about moving those definitions into the dpdk-ci repo, which I think makes sense. Second, there isn't an operating system to "maintain" since it's what's inside the container images, which are periodically rebuilt, but pretty much treated as ephemeral. Assuming the container bases / distros have the updated libabigail version packaged with them. Cheers, Lincoln On Fri, Apr 16, 2021 at 8:32 AM Aaron Conole wrote: > David Marchand writes: > > > On Tue, Apr 13, 2021 at 5:15 AM Xueming Li wrote: > >> diff --git a/lib/librte_eal/include/rte_devargs.h > b/lib/librte_eal/include/rte_devargs.h > >> index 296f19324f..134b44a887 100644 > >> --- a/lib/librte_eal/include/rte_devargs.h > >> +++ b/lib/librte_eal/include/rte_devargs.h > >> @@ -60,16 +60,16 @@ struct rte_devargs { > >> /** Name of the device. */ > >> char name[RTE_DEV_NAME_MAX_LEN]; > >> RTE_STD_C11 > >> - union { > >> - /** Arguments string as given by user or "" for no argument. */ > >> - char *args; > >> + union { /**< driver-related part of device string. */ > >> + const char *args; /**< legacy name. */ > >> const char *drv_str; > >> }; > >> struct rte_bus *bus; /**< bus handle. */ > >> struct rte_class *cls; /**< class handle. */ > >> const char *bus_str; /**< bus-related part of device string. */ > >> const char *cls_str; /**< class-related part of device string. > */ > >> - const char *data; /**< Device string storage. */ > >> + char *data; > >> + /**< Raw string including bus, class and driver arguments. */ > >> }; > >> > >> /** > > > > - Flagging this patch for info and its impact on UNH jobs. > > > > This change is fine, but older libabigail versions could not deal with > > such changes (anonymous union, changes of const fields). > > This results in an ABI check failure in the UNH x86 job on Ubuntu > > 18.04 (and for some people not using recent libabigail). > > I can see the ARM job passes fine, so I suppose it is using a more > > recent libabigail (running Ubuntu 20.04 maybe?). > > > > We either need to disable this x86 job or update its libabigail > > package (maybe aligning with what we have for public CI which is > > libabigail 1.8 manually compiled). > > > > > > - For the longer term, what do you think of using/extending the .ci/ > > scripts for use by UNH jobs? > > I think it would be great if we had some of the scripts shared as a > common resource. That would also help us to look at fixes / changes > when needed. > > -- *Lincoln Lavoie* Principal Engineer, Broadband Technologies 21 Madbury Rd., Ste. 100, Durham, NH 03824 lylavoie@iol.unh.edu https://www.iol.unh.edu +1-603-674-2755 (m) --0000000000003287ae05c0165f23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All= of the UNH ABI testing is moving info containers, so it can be run on top = of each OS, alongside the other compile and unit testing. This is actually= =C2=A0ready now, but hasn't been pushed live this week, because of the = backlog in the system because of the DTS failure.=C2=A0 The additional=C2= =A0compile jobs are already online now, it's just ABI that hasn't b= een pushed live.=C2=A0=C2=A0

This means the current ABI (what is reporting=C2=A0right now) is runnin= g on 18.04 for x86 and 20.04 for aarch64.=C2=A0 The aarch64 one will contin= ue forward, because we're not going to moving to emulated environments = for testing on that architecture.

This has two implications, first, the scripts for running ABI (a= nd the other tests) become part of the container definition, and at the las= t meeting we talked about moving those definitions=C2=A0into the dpdk-ci re= po, which I think makes sense.=C2=A0 Second, there isn't an operating s= ystem to "maintain" since it's what's inside the containe= r images, which are periodically=C2=A0rebuilt, but pretty much treated as e= phemeral.=C2=A0 Assuming the container bases / distros have the updated=C2= =A0libabigail=C2=A0version packaged with them.=C2=A0=C2=A0

Cheers,
Lincoln

On Fri, Apr 16, = 2021 at 8:32 AM Aaron Conole <acon= ole@redhat.com> wrote:
David Marchand <david.marchand@redhat.com> writes:

> On Tue, Apr 13, 2021 at 5:15 AM Xueming Li <xuemingl@nvidia.com> wrote:
>> diff --git a/lib/librte_eal/include/rte_devargs.h b/lib/librte_eal= /include/rte_devargs.h
>> index 296f19324f..134b44a887 100644
>> --- a/lib/librte_eal/include/rte_devargs.h
>> +++ b/lib/librte_eal/include/rte_devargs.h
>> @@ -60,16 +60,16 @@ struct rte_devargs {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/** Name of the device. */
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0char name[RTE_DEV_NAME_MAX_LEN];<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RTE_STD_C11
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0union {
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0/** Arguments string as given by user = or "" for no argument. */
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0char *args= ;
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0union { /**< driver-related part of= device string. */
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const char= *args; /**< legacy name. */
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const= char *drv_str;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct rte_bus *bus; /**< bus = handle. */
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct rte_class *cls; /**< cl= ass handle. */
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const char *bus_str; /**< bus-= related part of device string. */
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const char *cls_str; /**< clas= s-related part of device string. */
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0const char *data; /**< Device strin= g storage. */
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0char *data;
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/**< Raw string including bus, clas= s and driver arguments. */
>>=C2=A0 };
>>
>>=C2=A0 /**
>
> - Flagging this patch for info and its impact on UNH jobs.
>
> This change is fine, but older libabigail versions could not deal with=
> such changes (anonymous union, changes of const fields).
> This results in an ABI check failure in the UNH x86 job on Ubuntu
> 18.04 (and for some people not using recent libabigail).
> I can see the ARM job passes fine, so I suppose it is using a more
> recent libabigail (running Ubuntu 20.04 maybe?).
>
> We either need to disable this x86 job or update its libabigail
> package (maybe aligning with what we have for public CI which is
> libabigail 1.8 manually compiled).
>
>
> - For the longer term, what do you think of using/extending the .ci/ > scripts for use by UNH jobs?

I think it would be great if we had some of the scripts shared as a
common resource.=C2=A0 That would also help us to look at fixes / changes when needed.



--
Lincoln Lavoie
Prin= cipal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, = Durham, NH 03824
+1-603-674-= 2755 (m)

--0000000000003287ae05c0165f23--