[dpdk-test-report] |FAILURE| pw40074 [PATCH] dev Digest Vol 195 Issue 45 dev Digest Vol 195 Issue 45Send dev mailing list submissions todev@dpdk.orgTo subscribe or unsubscribe via the World Wide Web visithttps://dpdk.org/ml/listinfo/devor via email send a message with subject or body 'help' todev-request@dpdk.orgYou can reach the person managing the list atdev-owner@dpdk.orgWhen replying please edit your Subject line so it is more specific than "Re: Contents of dev digest..."Today's Topics: 1. Re: [PATCH 1/4] app: add LDFLAGS -latomic to link atomic lib (Jerin Jacob) 2. [PATCH v2] net/tap: perform proto field update for tunonly (Vipin Varghese) 3. Re: [PATCH] net/tap: perform proto field update for tun only (Varghese Vipin) 4. Re: [PATCH 2/4] Driver/Mellanox: fix PMD compiling issue (Jerin Jacob)----------------------------------------------------------------------Message: 1Date: Tue 15 May 2018 14:37:01 +0530 Re: [PATCH] [PATCH 1/4] app: add LDFLAGS -latomic to linkatomic libMessage-ID: <20180515090700.GA10539@jerin>Content-Type: text/plain; charset=us-ascii-----Original Message-----> Date: Tue 15 May 2018 04:28:41 -0400> [PATCH] [PATCH 1/4] app: add LDFLAGS -latomic to link> atomic lib> X-Mailer: git-send-email 2.1.4>> For ARM64 platform libdpdk.a includes the> librte_pmd_octeontx_ssovf.a which requires the libatomic.a> support.The atomic lib is built-in in the gcc toolchain but for clang it has to be explicitly linked.> For more details please refer to> https://clang.llvm.org/docs/Toolchain.html>> ~/dpdk/build/lib/librte_pmd_octeontx_ssovf.a(timvf_worker.o): In function `timvf_timer_cancel_burst':> timvf_worker.c:(.text+0x80): undefined reference to `__atomic_fetch_add_8'> /home/gavin/arm_repo/dpdk/build/lib/librte_pmd_octeontx_ssovf.a(timvf_worker.o): In function `timvf_timer_arm_burst_sp':> timvf_worker.c:(.text+0x200): undefined reference to `__atomic_fetch_add_8'> timvf_worker.c:(.text+0x244): undefined reference to `__atomic_store_2'> timvf_worker.c:(.text+0x278): undefined reference to `__atomic_fetch_add_4'> timvf_worker.c:(.text+0x30c): undefined reference to `__atomic_store_2'>> Signed-off-by: Gavin Hu <gavin.hu@arm.com>> Reviewed-by: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>Following patch is part of upstream. Are you testing with following patch/upstream.With this patch from Nikhilesh this __ atomic__ compiling issue was gone.The two patches fix the same issue.Should I abandon my patch?I see this note on: https://clang.llvm.org/docs/Toolchain.htmlNoteClang does not currently automatically link against libatomic when using libgcc_s. You may need to manually add -latomic to support this configuration when using non-native atomic operations (if you see link errors referring to __atomic_* functions).commit 55fbc92d7800100628579643c9ee2770614fef10Author: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>Date: Wed May 9 02:56:00 2018 +0530 event/octeontx: fix build with clang 6 Clang 6 & 7 fail to naturally align packed structs due to this clang can't use 8byte atomic primitives and splits them into lesser atomic primitives. To use lesser atomic primitives we need to link libatomic (-latomic) instead supply alignment attribute to the compiler. timvf_worker.c:(.text+0x498): undefined reference to `__atomic_fetch_add_8' timvf_worker.c:(.text+0x525): undefined reference to `__atomic_store_2' timvf_worker.c:(.text+0x557): undefined reference to `__atomic_fetch_add_4' timvf_worker.c:(.text+0x5de): undefined reference to `__atomic_store_2' Fixes: f874c1eb1519 ("event/octeontx: create and free timeradapter") Reported-by: Andrew Rybchenko <arybchenko@solarflare.com> Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>> ---> mk/rte.app.mk | 1 +> 1 file changed 1 insertion(+)>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 438f99d..bca8325> 100644> --- a/mk/rte.app.mk> +++ b/mk/rte.app.mk> @@ -51 6 +51 7 @@ endif>> # Link only the libraries used in the application LDFLAGS +=> --as-needed> +LDFLAGS += -latomic>> # default path for libs> _LDLIBS-y += -L$(RTE_SDK_BIN)/lib> --> 2.1.4>------------------------------Message: 2Date: Tue 15 May 2018 20:19:40 +0530 [PATCH] [PATCH v2] net/tap: perform proto field update fortunonlyMessage-ID:<1526395780-105792-1-git-send-email-vipin.varghese@intel.com>The TX function is shared between TAP and TUN PMD. Checking TUN-TAPtype field will ensure the TAP PMD will always have protocol fieldas 0.Signed-off-by: Vipin Varghese <vipin.varghese@intel.com>Suggested-by: Ferruh Yigit <ferruh.yigit@intel.com>---Changes in V2:updated in comment wording - Keith Wilesremove debug print from tx code - Keith Wiles--- drivers/net/tap/rte_eth_tap.c | 48 ++++++++++++++++++++++++++----------------- drivers/net/tap/rte_eth_tap.h | 10 +++++++++ 2 files changed 39 insertions(+) 19 deletions(-)--2.7.4------------------------------Message: 3Date: Tue 15 May 2018 09:08:49 +0000 Re: [PATCH] [PATCH] net/tap: perform proto field updatefor tun onlyMessage-ID:<4C9E0AB70F954A408CC4ADDBF0F8FA7D4D1EB6B2@BGSMSX101.gar.corp.intel.com>Content-Type: text/plain; charset="utf-8"Thanks Keith I have made changes and shared v2 patch for both the suggestions.ThanksVipin Varghese<snipped>> > +/*> > + * TUN and TAP are created with IFF_NO_PI disabled.> > + * For TUN PMD this mandatory as fields are used by> > + * Kernel tun.c to determine whether its IP or non IP> > + * packets.> > + *> > + * The logic fetches the first byte of data from mbuf.> > + * compares whether its v4 or v6. If none match default> > + * value 0x00 is taken for protocol field.>> Little reword and remove the ?.? at end of first line.>> The logic fetches the first byte of data from mbuf then compares whether it is v4> or v6. If not equal to zero then it must be a protocol field.>>>> > + */> > +char *buff_data = rte_pktmbuf_mtod(seg void *); > > +j = (*buff_data & 0xf0); > > +pi.proto = (j == 0x40) ? 0x0008 :> > +(j == 0x60) ? 0xdd86 : 0x00; > > +printf("j %x pi proto %x\n" j pi.proto); >> Should this not be a LOG message or is this debug that was not removed? If log> message then add move text to explain the output better.><snipped>------------------------------Message: 4Date: Tue 15 May 2018 14:41:42 +0530 Re: [PATCH] [PATCH 2/4] Driver/Mellanox: fix PMD compilingissueMessage-ID: <20180515091141.GB10539@jerin>Content-Type: text/plain; charset=us-ascii-----Original Message-----> Date: Tue 15 May 2018 04:28:42 -0400>

[dpdk-test-report] |FAILURE| pw40074 [PATCH] dev Digest Vol 195 Issue 45 dev Digest Vol 195 Issue 45Send dev mailing list submissions todev@dpdk.orgTo subscribe or unsubscribe via the World Wide Web visithttps://dpdk.org/ml/listinfo/devor via email send a message with subject or body 'help' todev-request@dpdk.orgYou can reach the person managing the list atdev-owner@dpdk.orgWhen replying please edit your Subject line so it is more specific than "Re: Contents of dev digest..."Today's Topics: 1. Re: [PATCH 1/4] app: add LDFLAGS -latomic to link atomic lib (Jerin Jacob) 2. [PATCH v2] net/tap: perform proto field update for tunonly (Vipin Varghese) 3. Re: [PATCH] net/tap: perform proto field update for tun only (Varghese Vipin) 4. Re: [PATCH 2/4] Driver/Mellanox: fix PMD compiling issue (Jerin Jacob)----------------------------------------------------------------------Message: 1Date: Tue 15 May 2018 14:37:01 +0530 Re: [PATCH] [PATCH 1/4] app: add LDFLAGS -latomic to linkatomic libMessage-ID: <20180515090700.GA10539@jerin>Content-Type: text/plain; charset=us-ascii-----Original Message-----> Date: Tue 15 May 2018 04:28:41 -0400> [PATCH] [PATCH 1/4] app: add LDFLAGS -latomic to link> atomic lib> X-Mailer: git-send-email 2.1.4>> For ARM64 platform libdpdk.a includes the> librte_pmd_octeontx_ssovf.a which requires the libatomic.a> support.The atomic lib is built-in in the gcc toolchain but for clang it has to be explicitly linked.> For more details please refer to> https://clang.llvm.org/docs/Toolchain.html>> ~/dpdk/build/lib/librte_pmd_octeontx_ssovf.a(timvf_worker.o): In function `timvf_timer_cancel_burst':> timvf_worker.c:(.text+0x80): undefined reference to `__atomic_fetch_add_8'> /home/gavin/arm_repo/dpdk/build/lib/librte_pmd_octeontx_ssovf.a(timvf_worker.o): In function `timvf_timer_arm_burst_sp':> timvf_worker.c:(.text+0x200): undefined reference to `__atomic_fetch_add_8'> timvf_worker.c:(.text+0x244): undefined reference to `__atomic_store_2'> timvf_worker.c:(.text+0x278): undefined reference to `__atomic_fetch_add_4'> timvf_worker.c:(.text+0x30c): undefined reference to `__atomic_store_2'>> Signed-off-by: Gavin Hu <gavin.hu@arm.com>> Reviewed-by: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>Following patch is part of upstream. Are you testing with following patch/upstream.With this patch from Nikhilesh this __ atomic__ compiling issue was gone.The two patches fix the same issue.Should I abandon my patch?I see this note on: https://clang.llvm.org/docs/Toolchain.htmlNoteClang does not currently automatically link against libatomic when using libgcc_s. You may need to manually add -latomic to support this configuration when using non-native atomic operations (if you see link errors referring to __atomic_* functions).commit 55fbc92d7800100628579643c9ee2770614fef10Author: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>Date: Wed May 9 02:56:00 2018 +0530 event/octeontx: fix build with clang 6 Clang 6 & 7 fail to naturally align packed structs due to this clang can't use 8byte atomic primitives and splits them into lesser atomic primitives. To use lesser atomic primitives we need to link libatomic (-latomic) instead supply alignment attribute to the compiler. timvf_worker.c:(.text+0x498): undefined reference to `__atomic_fetch_add_8' timvf_worker.c:(.text+0x525): undefined reference to `__atomic_store_2' timvf_worker.c:(.text+0x557): undefined reference to `__atomic_fetch_add_4' timvf_worker.c:(.text+0x5de): undefined reference to `__atomic_store_2' Fixes: f874c1eb1519 ("event/octeontx: create and free timeradapter") Reported-by: Andrew Rybchenko <arybchenko@solarflare.com> Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>> ---> mk/rte.app.mk | 1 +> 1 file changed 1 insertion(+)>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 438f99d..bca8325> 100644> --- a/mk/rte.app.mk> +++ b/mk/rte.app.mk> @@ -51 6 +51 7 @@ endif>> # Link only the libraries used in the application LDFLAGS +=> --as-needed> +LDFLAGS += -latomic>> # default path for libs> _LDLIBS-y += -L$(RTE_SDK_BIN)/lib> --> 2.1.4>------------------------------Message: 2Date: Tue 15 May 2018 20:19:40 +0530 [PATCH] [PATCH v2] net/tap: perform proto field update fortunonlyMessage-ID:<1526395780-105792-1-git-send-email-vipin.varghese@intel.com>The TX function is shared between TAP and TUN PMD. Checking TUN-TAPtype field will ensure the TAP PMD will always have protocol fieldas 0.Signed-off-by: Vipin Varghese <vipin.varghese@intel.com>Suggested-by: Ferruh Yigit <ferruh.yigit@intel.com>---Changes in V2:updated in comment wording - Keith Wilesremove debug print from tx code - Keith Wiles--- drivers/net/tap/rte_eth_tap.c | 48 ++++++++++++++++++++++++++----------------- drivers/net/tap/rte_eth_tap.h | 10 +++++++++ 2 files changed 39 insertions(+) 19 deletions(-)--2.7.4------------------------------Message: 3Date: Tue 15 May 2018 09:08:49 +0000 Re: [PATCH] [PATCH] net/tap: perform proto field updatefor tun onlyMessage-ID:<4C9E0AB70F954A408CC4ADDBF0F8FA7D4D1EB6B2@BGSMSX101.gar.corp.intel.com>Content-Type: text/plain; charset="utf-8"Thanks Keith I have made changes and shared v2 patch for both the suggestions.ThanksVipin Varghese<snipped>> > +/*> > + * TUN and TAP are created with IFF_NO_PI disabled.> > + * For TUN PMD this mandatory as fields are used by> > + * Kernel tun.c to determine whether its IP or non IP> > + * packets.> > + *> > + * The logic fetches the first byte of data from mbuf.> > + * compares whether its v4 or v6. If none match default> > + * value 0x00 is taken for protocol field.>> Little reword and remove the ?.? at end of first line.>> The logic fetches the first byte of data from mbuf then compares whether it is v4> or v6. If not equal to zero then it must be a protocol field.>>>> > + */> > +char *buff_data = rte_pktmbuf_mtod(seg void *); > > +j = (*buff_data & 0xf0); > > +pi.proto = (j == 0x40) ? 0x0008 :> > +(j == 0x60) ? 0xdd86 : 0x00; > > +printf("j %x pi proto %x\n" j pi.proto); >> Should this not be a LOG message or is this debug that was not removed? If log> message then add move text to explain the output better.><snipped>------------------------------Message: 4Date: Tue 15 May 2018 14:41:42 +0530 Re: [PATCH] [PATCH 2/4] Driver/Mellanox: fix PMD compilingissueMessage-ID: <20180515091141.GB10539@jerin>Content-Type: text/plain; charset=us-ascii-----Original Message-----> Date: Tue 15 May 2018 04:28:42 -0400>

[sys_stv]

[-- Attachment #1: Type: text/plain, Size: 3871 bytes --]

Test-Label: Intel-compilation
Test-Status: FAILURE
http://dpdk.org/patch/40074

_apply patch file failure_

Submitter: gavin hu <gavin.hu@arm.com>
Date: Wed, 16 May 2018 02:08:48 +0000Tue, 15 May 2018 14:37:01 +0530Tue, 15 May 2018 04:28:41 -0400  Wed May 9 02:56:00 2018 +0530Tue, 15 May 2018 20:19:40 +0530Tue, 15 May 2018 09:08:49 +0000Tue, 15 May 2018 14:41:42 +0530Tue, 15 May 2018 04:28:42 -0400
DPDK git baseline: Repo:dpdk-next-eventdev, Branch:master, CommitID:3c955492b601d65402c02ac81dfdc7eeb62f23c9
                   Repo:dpdk-next-crypto, Branch:master, CommitID:e0d88a394e91f446234aa04d0f9e01c150b0d347
                   Repo:dpdk-next-net, Branch:master, CommitID:08b7521c352952e4abe8cd6ed9e5e5084d5cfa9a
                   Repo:dpdk-next-virtio, Branch:master, CommitID:b88ef5968604fb493930fa221672a4258d107852
                   Repo:dpdk, Branch:master, CommitID:08b7521c352952e4abe8cd6ed9e5e5084d5cfa9a
                   
Apply patch file failed:
Repo: dpdk
40074:
patching file drivers/net/tap/rte_eth_tap.c
Hunk #1 FAILED at 115.
Hunk #2 FAILED at 502.
Hunk #3 FAILED at 1052.
Hunk #4 FAILED at 1386.
Hunk #5 FAILED at 1421.
Hunk #6 FAILED at 1440.
Hunk #7 FAILED at 1812.
Hunk #8 FAILED at 1820.
8 out of 8 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.c.rej
patching file drivers/net/tap/rte_eth_tap.h
Hunk #1 succeeded at 23 with fuzz 2.
Hunk #2 FAILED at 45.
Hunk #3 FAILED at 55.
Hunk #4 FAILED at 64.
3 out of 4 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.h.rej

Repo: dpdk-next-crypto
40074:
patching file drivers/net/tap/rte_eth_tap.c
Hunk #1 FAILED at 115.
Hunk #2 FAILED at 502.
Hunk #3 FAILED at 1052.
Hunk #4 FAILED at 1386.
Hunk #5 FAILED at 1421.
Hunk #6 FAILED at 1440.
Hunk #7 FAILED at 1812.
Hunk #8 FAILED at 1820.
8 out of 8 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.c.rej
patching file drivers/net/tap/rte_eth_tap.h
Hunk #1 succeeded at 23 with fuzz 2.
Hunk #2 FAILED at 45.
Hunk #3 FAILED at 55.
Hunk #4 FAILED at 64.
3 out of 4 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.h.rej

Repo: dpdk-next-net
40074:
patching file drivers/net/tap/rte_eth_tap.c
Hunk #1 FAILED at 115.
Hunk #2 FAILED at 502.
Hunk #3 FAILED at 1052.
Hunk #4 FAILED at 1386.
Hunk #5 FAILED at 1421.
Hunk #6 FAILED at 1440.
Hunk #7 FAILED at 1812.
Hunk #8 FAILED at 1820.
8 out of 8 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.c.rej
patching file drivers/net/tap/rte_eth_tap.h
Hunk #1 succeeded at 23 with fuzz 2.
Hunk #2 FAILED at 45.
Hunk #3 FAILED at 55.
Hunk #4 FAILED at 64.
3 out of 4 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.h.rej

Repo: dpdk-next-virtio
40074:
patching file drivers/net/tap/rte_eth_tap.c
Hunk #1 FAILED at 115.
Hunk #2 FAILED at 502.
Hunk #3 FAILED at 1052.
Hunk #4 FAILED at 1386.
Hunk #5 FAILED at 1421.
Hunk #6 FAILED at 1440.
Hunk #7 FAILED at 1812.
Hunk #8 FAILED at 1820.
8 out of 8 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.c.rej
patching file drivers/net/tap/rte_eth_tap.h
Hunk #1 succeeded at 23 with fuzz 2.
Hunk #2 FAILED at 45.
Hunk #3 FAILED at 55.
Hunk #4 FAILED at 64.
3 out of 4 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.h.rej

Repo: dpdk-next-eventdev
40074:
patching file drivers/net/tap/rte_eth_tap.c
Hunk #1 FAILED at 115.
Hunk #2 FAILED at 502.
Hunk #3 FAILED at 1052.
Hunk #4 FAILED at 1386.
Hunk #5 FAILED at 1421.
Hunk #6 FAILED at 1440.
Hunk #7 FAILED at 1812.
Hunk #8 FAILED at 1820.
8 out of 8 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.c.rej
patching file drivers/net/tap/rte_eth_tap.h
Hunk #1 succeeded at 23 with fuzz 2.
Hunk #2 FAILED at 45.
Hunk #3 FAILED at 55.
Hunk #4 FAILED at 64.
3 out of 4 hunks FAILED -- saving rejects to file drivers/net/tap/rte_eth_tap.h.rej


DPDK STV team