I ask if there is a publicly available recording of
> the training session you mentioned? (or similar training sessions done in
> the past).
>
> Thank you,
> Mattia
> On 31/05/2024 14:40, Lincoln Lavoie wrote:
>
>
> You don't often get email from lylav...@iol.un
t,
> I don't know if this is managed elsewhere.
>
> Given all that, I'm still of the idea that could be useful to have those
> kind of headers directly in DPDK
> but I'm open to reconsider my statement, please let me know if you have
> more information regarding
> thi
rest?
>
> If there is interest I would be happy to share what I developed up to
> now to receive comments and/or assistance on how to make it fully
> functioning.
>
> Best regards,
> Mattia
>
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21
gt; #9 0x55fb667d in rdline_char_in (rdl=0x6a8b2fb0, c=10
> '\n') at ../lib/cmdline/cmdline_rdline.c:444
> > > > #10 0x55fb19bd in cmdline_in (cl=0x6a8b2fa0,
> buf=0x7fffe3f0 "fbarray_autotest\n", size=17)
> > > >
to run. Unit tests are run in automated
environments, across multiple CI systems, i.e. UNH-IOL Community Lab,
GitHub, etc. Those environments are typically virtualized and I don't
think the unit tests should require turning down to the level of CPU clock
ticks. Those tests are likely better suited to dedicated performance
environments, where the complete host is tightly controlled, for the
purpose of repeatable and deterministic results on things like packet
throughput, etc.
Cheers,
Lincoln
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
uot;supported" for dpdk. That
version would be used for all CI testing.
Cheers,
Lincoln
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
Thanks David,
Owen is taking care of that this morning and will confirm back when it's
disabled on the DPDK main.
Cheers,
Lincoln
On Tue, Jul 19, 2022 at 6:36 AM David Marchand
wrote:
> On Mon, Jul 18, 2022 at 6:21 PM Lincoln Lavoie
> wrote:
> > With the 22.07 release, I
erved.
> > Special handling of removed drivers is also dropped in check-abi.sh and
> > a note has been added in libabigail.abignore as a reminder.
> >
> > Signed-off-by: David Marchand
>
> Just a heads-up that once this patch is merged, the ABI check will
> hav
rerun, and
> > we'll need to track which rerun messages we've accepted). The
> > convention needs to be something we all can work with (ie: /Re-check:
> > [checkname] or something as a single line in the email).
> >
> > This is just a start to identify and exp
cific hw requirements, some time ago.
> See https://git.dpdk.org/dpdk/commit/?id=e0f4a0ed4237
>
>
> --
> David Marchand
>
>
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
4 AM Dumitrescu, Cristian <
cristian.dumitre...@intel.com> wrote:
>
>
> > -Original Message-
> > From: Thomas Monjalon
> > Sent: Friday, November 19, 2021 7:26 AM
> > To: Dumitrescu, Cristian ; David Marchand
> > ; Lincoln Lavoie ;
> > Ajmera, Megha ; Sin
unning the tests within the containers along the lines
of the CPU pinning requirements that might be assumed by the unit tests. So
far, everything he has tried has still had the similar failures / issues.
We are still looking into it, so the bug is not sitting without action,
just no final resolution.
Cheers,
Lincoln
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
On Wed, Nov 3, 2021 at 9:16 AM Maxime Coquelin
wrote:
>
>
> On 11/3/21 14:11, Lincoln Lavoie wrote:
> >
> >
> >
> > On Wed, Nov 3, 2021 at 5:53 AM Maxime Coquelin
> > mailto:maxime.coque...@redhat.com>> wrote:
> >
> >
> >
>
SPDK team.
>
> The Bz has been filed:
> https://bugs.dpdk.org/show_bug.cgi?id=876
>
> > Maxime
> >> Thanks.
> >>
> >>
>
> SDPK tests have been disabled in the CI testing and shouldn't run for any
new patches. Anything that was already in the
ttps://patches.dpdk.org/patch/100042 (patchset
> >> https://lab.dpdk.org/results/dashboard/patchsets/19066/).
> >> You should see the new results reported over email soon.
> >>
> >> Thanks,
> >> Brandon
> >>
> >>
> >> On Mon, Oct 11,
right line (Thomas), add SPDX header for the new test file
> > (BTW, why didn't the CI complain in previous versions?)
>
> Probably because the CI doesn't run the script devtools/check-spdx-tag.sh
> Cc c...@dpdk.org to add this test.
>
>
>
>
--
*Lincoln Lav
gt;> -Original Message-
> >> From: Yigit, Ferruh
> >> Sent: Wednesday, October 6, 2021 5:46 AM
> >> To: Lincoln Lavoie ; dev ; Yang,
> Qiming
> >> ; Zhang, Qi Z
> >> Cc: c...@dpdk.org; Aaron Conole ; dpdklab
> >> ; Sin
:
> On 10/5/2021 8:09 PM, Lincoln Lavoie wrote:
> > Hello Qiming and Qi,
> >
> > The CI is picking up failures when building on RHEL7, where warnings are
> > being treated as errors. This looks like something has been merged into
> > the mainline, as it's faili
results/dashboard/patchsets/19162/
Cheers,
Lincoln
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
ystem.
Cheers,
Lincoln
On Tue, Aug 24, 2021 at 3:58 AM David Marchand
wrote:
> Hello Lincoln,
>
> On Tue, Aug 17, 2021 at 2:04 PM Lincoln Lavoie
> wrote:
> >
> > Hi David,
> >
> > ABI testing was disable / stopped on Friday in the Community CI lab.
> Patches fro
nks.
>
>
> On this last subject, this mail is a ping to CI labs owners.
> 21.11 release won't preserve ABI compat with previous releases, so
> please disable ABI checks until 22.02.
>
>
> --
> David Marchand
>
>
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
Gusy4yM/edit#
> <https://docs.google.com/document/d/1c5S0_mZzFvzZfYkqyORLT2-qNvUb-fBdjA6DGusy4yM/edit>
>
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
iz(value) # not COFF-specific
> >
> > def get_value(self, offset, size):
> > section = self._symbol["st_shndx"]
>
> There are CI failures that seem unrelated to this patch:
> some tests with NICs that I can't check
> and an Arch Linux build
luded from ..\drivers\common/mlx5/mlx5_common.h:17:
> > >> ..\lib/librte_eal/windows/include\rte_os_shim.h:22:51: warning:
> > >> token pasting of ',' and __VA_ARGS__ is a GNU extension
> > >> [-Wgnu-zero-variadic-macro-arguments]
> > >> #define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
> > >> ^
> > >> However don't see it in CI, I'm using clang version 9.0.1
> > >
> > > It seems we should improve our CI.
> > > Please open suggestions in the CI bugzilla.
> >
> > Please do.
> >
> > Will this only be caught by mingw64 on windows? Will we get the same
> > issues with a linux mingw install? I'm guessing yes, but don't know
> > mingw very well. We may be able to install the mingw package under our
> > github actions pipeline.
>
> Yes, Linux MinGW-w64 produces the same warning (about strncasecmp).
> __VA_ARGS__ warning won't show up with GNU compiler, obviously.
> It may with ICC, but I don't have it to check.
>
> I figured out it's not --default-library=static, but --buildtype=debug that
> caues the arning to appear, my mistake in previous message.
>
--
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
Thomas Monjalon wrote:
> 16/04/2021 14:43, Lincoln Lavoie:
> > 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
ther 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
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
> > https://lab.dpdk.org/results/dashboard/results/results-
> > uploads/test_runs/2363efb43157465db3228c34c00ebd57/log_upload_file/20
> > 21/2/dpdk_f6f2d2240153_15524_2021-02-04_22-59-59_NA.zip
> >
> > Is it possible to turn on more verbose logging during the c
ng heuristics. Similar issue existed
> in
> > >> librte_acl (at least a year ago win GCC 6, I believe), where GCC
> generated
> > >> incorrect code unless certain functions had been inlined (caught by
> test app).
> > >> No an AVX expert, just my 2c.
> &
the baseline's expected values for the Intel NICs
> > and rerun the test on this patch?
> > >
> >
> > Zhaoyan said that the baseline is calculated dynamically,
> > what I understand is baseline set based on previous days performance
> > result, so
> &g
ot be closed until
the issue is fixed and the test can be re-enabled. This is so we don't
lose track of anything.
Cheers,
Lincoln
On Mon, Jan 11, 2021 at 9:05 AM Jerin Jacob wrote:
>
>
> On Mon, Jan 11, 2021 at 7:28 PM Lincoln Lavoie
> wrote:
>
>> Hi All,
>>
>&g
t; > Did it ever work?
>
> No. There are a lot of sync barriers are missing in the distributor
> library.
> Since evendev is kind of replacing this library, we made the fix as
> low priority.
>
>
>
> >
> >
> >
> > --
> > David Marchand
> >
>
--
*Lincoln Lavoie*
Senior Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>
icket must remain open until the test is
re-enabled.
Community CI Minutes:
https://mails.dpdk.org/archives/ci/2020-November/000894.html
Example Bugzilla Ticket: https://bugs.dpdk.org/show_bug.cgi?id=579
Cheers,
Lincoln
--
Lincoln Lavoie
Senior Engineer, Broadband Technologies
21 Madbury Rd., Ste
ndar evite, please just unicast back
to me and I'll make sure you're added.
Cheers,
Lincoln
--
*Lincoln Lavoie*
Senior Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu/>
VATE |
> > > MAP_ANONYMOUS | additional_flags, -1, 0);
> > > if (bar_addr != MAP_FAILED) {
> > > - void *map_addr = NULL;
> > > + /* Set non NULL initial value for in case of no PCI
> mapping */
>
discussion on
the bug here: https://bugs.dpdk.org/show_bug.cgi?id=497
Cheers,
Lincoln
--
*Lincoln Lavoie*
Senior Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu/>
oth on/off cases.
>
> > Please let me know if there is anything I need to add on or if there are
> > certain cases I need to be aware of.
>
> Anyone else has ideas about what to test and corner cases?
>
> >
> > Thanks,
> > David Liu
> > UNH Interoperab
assuming the NIC supported multiple speeds), to
change either the module or the DAC. We're trying to avoid anything that
would require physical changes that can't be forced through
the tester (i.e. disable the port connected to the DUT for a link down,
etc.)
--
*Lincoln Lavoie*
37 matches
Mail list logo
