Re: [vpp-dev] ACL Plugin: tagged interface

2017-11-28 Thread khers
Dear Andrew

Thanks for your attention, Yes of course I pushed to gerrit with id 9615.

Regards,
Khers

On Tue, Nov 28, 2017 at 8:37 PM, Andrew Yourtchenko 
wrote:

> Dear Khers,
>
> I believe you are right. That might not be all though... “dot1q”/“dot1ad”
> mask value constant does not appear to make sense to me now.
>
> They should be “XX XX” to mask out the bits and also should be set
> accordingly to the proper values during the addition of the sessions. (I
> suppose might “kind of” work now but it is not correct..)
>
> Would you like to submit a gerrit to address these ?
>
> Good catch, thanks!
>
> --a
>
> > On 28 Nov 2017, at 12:24, khers  wrote:
> >
> > Dear vpp folks
> >
> > I think following line if function acl_add_vlan_session in acl.c line 635
> >
> >   memset ([idx], 0x00, 2);
> >
> > should change to
> >
> >   memset ([idx], 0xff, 2);
> >
> > because dot1ad_5tuple_mask and dot1q_5tuple_mask must have mask for
> IPv4/6, so memset to ff reset those mask to default values.
> >
> > Regards,
> > Khers
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] SR MPLS not effective

2017-11-28 Thread 薛欣颖

Hi Neale,

After add the 'mpls local-label add non-eos 33 mpls-lookup-in-table 0 ' on P,  
the mistake still exist.

create host-interface name eth2 mac 00:0c:29:0f:e2:a8 
create host-interface name eth3 mac 00:0c:29:0f:e2:b2 
set interface state host-eth2 up 
set interface state host-eth3 up 
set interface ip address host-eth3 12.1.1.1/24 
mpls table add 0 
set interface mpls host-eth2 enable 
set interface mpls host-eth3 enable 
set interface ip address host-eth2 14.1.1.2/24 
create mpls tunnel out-label 60 via 12.1.1.2 host-eth3 
set interface state mpls-tunnel0 up 
sr mpls policy add bsid 33 next 60 
sr mpls steer l3 23.1.1.0/24 via sr policy bsid 33 
set interface mpls mpls-tunnel0 enable 
mpls local-label add non-eos 33 mpls-lookup-in-table 0   // local-label 
33/non-eos configured

the mistake is the same as before:
00:06:02:539782: af-packet-input 
af_packet: hw_if_index 1 next-index 4 
tpacket2_hdr: 
status 0x2001 len 86 snaplen 86 mac 66 net 80 
sec 0x5a1e5992 nsec 0x193b68e0 vlan 0 
00:06:02:539813: ethernet-input 
MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8 
00:06:02:539869: mpls-input 
MPLS: next mpls-lookup[1] label 33 ttl 255 
00:06:02:539878: mpls-lookup 
MPLS: next [0], lookup fib index 0, LB index 25 hash 0 label 33 eos 0 
00:06:02:539889: error-drop 
mpls-input: MPLS DROP DPO

Is there any example on SR MPLS configuration  I can get?

Thanks,
Xyxue


 
From: Neale Ranns (nranns)
Date: 2017-11-28 20:29
To: 薛欣颖; Pablo Camarillo (pcamaril); vpp-dev
Subject: Re: [vpp-dev] SR MPLS not effective
Hi Xyxue,
 
Your trace says:
 
00:01:54:346249: mpls-lookup 
MPLS: next [0], lookup fib index 0, LB index 26 hash 0 label 33 eos 0 
 
so the packet required an MPLS lookup on label 33 non-eos. Your config has no 
local-label 33/non-eos configured, so the packet is dropped.
 
/neale
 
 
From:  on behalf of 薛欣颖 
Date: Tuesday, 28 November 2017 at 12:20
To: "Pablo Camarillo (pcamaril)" , vpp-dev 

Subject: Re: [vpp-dev] SR MPLS not effective
 
 
Hi Pablo,

After hearing your advice, I modified my configuration on P:

create host-interface name eth2 mac 00:0c:29:0f:e2:a8 
create host-interface name eth3 mac 00:0c:29:0f:e2:b2 
set interface state host-eth2 up 
set interface state host-eth3 up 
set interface ip address host-eth3 12.1.1.1/24 
mpls table add 0 
set interface mpls host-eth2 enable 
set interface mpls host-eth3 enable 
set interface ip address host-eth2 14.1.1.2/24 
create mpls tunnel out-label 60 via 12.1.1.2 host-eth3 
set interface state mpls-tunnel0 up 
sr mpls policy add bsid 33 next 60   //exchange the 
out-label to 60
sr mpls steer l3 23.1.1.0/24 via sr policy bsid 33
set interface mpls mpls-tunnel0 enable

the trace info on P:
00:01:54:346199: af-packet-input 
af_packet: hw_if_index 1 next-index 4 
tpacket2_hdr: 
status 0x2001 len 86 snaplen 86 mac 66 net 80 
sec 0x5a1d417b nsec 0xdffd3a9 vlan 0 
00:01:54:346226: ethernet-input 
MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8 
00:01:54:346243: mpls-input 
MPLS: next mpls-lookup[1] label 33 ttl 255 
00:01:54:346249: mpls-lookup 
MPLS: next [0], lookup fib index 0, LB index 26 hash 0 label 33 eos 0 
00:01:54:346259: error-drop 
mpls-input: MPLS DROP DPO 

The SR MPLS still not effctive. Is there any example on SR MPLS configuration?

Thanks,
Xyxue


 
From: Pablo Camarillo (pcamaril)
Date: 2017-11-28 18:16
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] SR MPLS not effective
Hi Xyxue,
 
Could you please explain what you want to achieve with this config? Where do 
you want to start your SR policy? 
None of the configs that you described below for P will work.  
 
In the case #1 you are creating a SR policy with BSID 33. Then for any packet 
with incoming label 33 you will push the SID list of the SR policy. However, 
you are also creating an mpls local-label for 33 as well which you do not need.
On top of that, you are configuring the SR policy with SID list < 60 >, but you 
have not set a local-label/route for 60. Hence packet will be dropped.
 
Thanks.
 
Cheers,
Pablo.
 
From:  on behalf of 薛欣颖 
Date: Tuesday, 28 November 2017 at 08:08
To: vpp-dev 
Subject: [vpp-dev] SR MPLS not effective
 
 
Hi guys,

I have tried every configuration I can guess. The sr mpls still not effective 
on my vpp.
Can you give me an effective configuration, or can you help figure out the 
error in my configuration?

PE1 - P - PE2

PE1 configuration:
  create host-interface name eth4 mac 00:0c:29:4d:af:b5
  create host-interface name eth2 mac 00:0c:29:4d:af:a1
  set interface state host-eth2 up
  set interface state host-eth4 up
  set interface ip table host-eth4 1
  set interface ip address host-eth2 14.1.1.1/24
  set interface ip address host-eth4 21.1.1.1/24
  create mpls tunnel out-label 33 out-label 53 via 14.1.1.2 host-eth2
  set interface state mpls-tunnel0 

[vpp-dev] problem in elog format

2017-11-28 Thread Juan Salmon
I want to use event-log and send string to one of elements of ed struct.
but the result is not correct.

the sample code:

ELOG_TYPE_DECLARE (e) = {
.format = "Test LOG: %s",
.format_args = "s20",
};
struct
{
u8 * err;
} * ed;


vlib_worker_thread_t * w = vlib_worker_threads + cpu_index;
ed = ELOG_TRACK_DATA (_global_main.elog_main, e,
w->elog_track);

ed->err = format (0,"%s", "This is a Test");


Could you please help me?


Best Regards,
Juan Salmon.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] ACL Plugin: tagged interface

2017-11-28 Thread Andrew Yourtchenko
Dear Khers,

I believe you are right. That might not be all though... “dot1q”/“dot1ad” mask 
value constant does not appear to make sense to me now.

They should be “XX XX” to mask out the bits and also should be set accordingly 
to the proper values during the addition of the sessions. (I suppose might 
“kind of” work now but it is not correct..)

Would you like to submit a gerrit to address these ?

Good catch, thanks!

--a

> On 28 Nov 2017, at 12:24, khers  wrote:
> 
> Dear vpp folks
> 
> I think following line if function acl_add_vlan_session in acl.c line 635
> 
>   memset ([idx], 0x00, 2);
> 
> should change to 
> 
>   memset ([idx], 0xff, 2);
> 
> because dot1ad_5tuple_mask and dot1q_5tuple_mask must have mask for IPv4/6, 
> so memset to ff reset those mask to default values.
> 
> Regards, 
> Khers
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] How to enable RSS in VPP

2017-11-28 Thread Dave Barach (dbarach)
You are sending traffic with more than one flow, correct?

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Saxena, Nitin
Sent: Tuesday, November 28, 2017 11:45 AM
To: vpp-dev@lists.fd.io
Cc: Athreya, Narayana Prasad 
Subject: [vpp-dev] How to enable RSS in VPP

HI,

I am using ConnectX-4 NIC which has Rx RSS support however I can see VPP is not 
using RSS feature with this NIC.
NIC is getting traffic from 1 queue only?  Is this can be fixed in VPP? If yes 
how?

Output from show hardware detail

==
UnknownEthernet32/0/0  1 up   UnknownEthernet32/0/0
  Ethernet address 24:8a:07:a4:6b:78
  Mellanox ConnectX-4 Family
carrier up full duplex speed 4 mtu 9216  promisc
pci id:device 15b3:1013 subsystem 15b3:0008
pci address:   :32:00.00
max rx packet len: 65536
max num of queues: rx 65535 tx 65535
promiscuous:   unicast on all-multicast on
vlan offload:  strip off filter off qinq off
rx offload caps:   vlan-strip ipv4-cksum udp-cksum tcp-cksum
tx offload caps:   vlan-insert ipv4-cksum udp-cksum tcp-cksum 
outer-ipv4-cksum
rss active:ipv4-udp
rss supported: none
rx queues 4, rx desc 1024, tx queues 5, tx desc 1024
cpu socket 0

tx frames ok 31003987272
tx bytes ok1860239236320
rx frames ok 63884415232
rx bytes ok3833064913920
extended stats:
  rx good packets63884415232
  tx good packets31003987272
  rx good bytes3833064913920
  tx good bytes1860239236320
  rx errors0
  tx errors0
  rx mbuf allocation errors0
  rx q0packets 0
  rx q0bytes   0
  rx q0errors  0
  rx q1packets 0
  rx q1bytes   0
  rx q1errors  0
  rx q2packets 0
  rx q2bytes   0
  rx q2errors  0
  rx q3packets   63884415232
  rx q3bytes   3833064913920
  rx q3errors  0
  tx q0packets 0
  tx q0bytes   0
  tx q1packets   31003987272
  tx q1bytes   1860239236320
  tx q2packets 0
  tx q2bytes   0
  tx q3packets 0
  tx q3bytes   0
  tx q4packets 0
  tx q4bytes   0


Regards,
Nitin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] How to enable RSS in VPP

2017-11-28 Thread Saxena, Nitin
HI,

I am using ConnectX-4 NIC which has Rx RSS support however I can see VPP is not 
using RSS feature with this NIC.
NIC is getting traffic from 1 queue only?  Is this can be fixed in VPP? If yes 
how?

Output from show hardware detail

==
UnknownEthernet32/0/0  1 up   UnknownEthernet32/0/0
  Ethernet address 24:8a:07:a4:6b:78
  Mellanox ConnectX-4 Family
carrier up full duplex speed 4 mtu 9216  promisc
pci id:device 15b3:1013 subsystem 15b3:0008
pci address:   :32:00.00
max rx packet len: 65536
max num of queues: rx 65535 tx 65535
promiscuous:   unicast on all-multicast on
vlan offload:  strip off filter off qinq off
rx offload caps:   vlan-strip ipv4-cksum udp-cksum tcp-cksum
tx offload caps:   vlan-insert ipv4-cksum udp-cksum tcp-cksum 
outer-ipv4-cksum
rss active:ipv4-udp
rss supported: none
rx queues 4, rx desc 1024, tx queues 5, tx desc 1024
cpu socket 0

tx frames ok 31003987272
tx bytes ok1860239236320
rx frames ok 63884415232
rx bytes ok3833064913920
extended stats:
  rx good packets63884415232
  tx good packets31003987272
  rx good bytes3833064913920
  tx good bytes1860239236320
  rx errors0
  tx errors0
  rx mbuf allocation errors0
  rx q0packets 0
  rx q0bytes   0
  rx q0errors  0
  rx q1packets 0
  rx q1bytes   0
  rx q1errors  0
  rx q2packets 0
  rx q2bytes   0
  rx q2errors  0
  rx q3packets   63884415232
  rx q3bytes   3833064913920
  rx q3errors  0
  tx q0packets 0
  tx q0bytes   0
  tx q1packets   31003987272
  tx q1bytes   1860239236320
  tx q2packets 0
  tx q2bytes   0
  tx q3packets 0
  tx q3bytes   0
  tx q4packets 0
  tx q4bytes   0


Regards,
Nitin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

2017-11-28 Thread Marco Varlese
Dear Dave,

By the look of it is seemed to have been an hiccup with the download or
that something spurious was left on the filesystem...
===
12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
opensuse/dpdk/dpdk-17.08.tar.xz and retry
12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
root/build-vpp-native/dpdk/.download.ok] Error 1
12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
12:08:13 make[2]: *** [ebuild-build] Error 2
12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
12:08:13 make[1]: *** [dpdk-build] Error 2
12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/build-root'
12:08:13 Makefile:333: recipe for target 'build-release' failed
12:08:13 make: *** [build-release] Error 2
12:08:13 Build step 'Execute shell' marked build as failure
===

Since the MD5 checksum on the DPDK tarball fails; to answer your
question, no, it has never happened to me to see this specific issue
before.

I don't think there's anything specific to the openSUSE setup and/or
scripts being executed. I'd rather feel is - as I said earlier -
something to do with an hiccup on the infrastructure side. The fact
that a 'recheck' made it passing I suppose it confirms my current
theory.

An idea: maybe, if it happens again, we might want to ask Vanessa to
see what's the status on the slave-node? Not sure if that could give us
some more insight of what's going on.


Cheers,
Marco

On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote:
> Marco,
> 
> Can you please take a look at the build failure encountered with http
> s://gerrit.fd.io/r/#/c/9582/ on the vpp-verify-master-opensuse
> jenkins job:
> 
> - %< -
> fd.io JJB  7:56 AM
> Patch Set 2: Verified-1
> Build Failed 
> https://jenkins.fd.io/job/vpp-verify-master-opensuse/459/ : FAILURE
> No problems were identified. If you know why this problem occurred,
> please add a suitable Cause for it. ( https://jenkins.fd.io/job/vpp-v
> erify-master-opensuse/459/ )
> Logs: https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-
> master-opensuse/459
> - %< --
> 
> From the logs, it appears that there is an issue related to building
> dpdk.  Have you seen this issue before?  If so, it this an
> infrastructure issue or something else?
> 
> Thanks,
> -daw-
>  ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

2017-11-28 Thread Marco Varlese
Dear Dave,

By the look of it is seemed to have been an hiccup with the download or
that something spurious was left on the filesystem...
===
12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
opensuse/dpdk/dpdk-17.08.tar.xz and retry
12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
root/build-vpp-native/dpdk/.download.ok] Error 1
12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
12:08:13 make[2]: *** [ebuild-build] Error 2
12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
12:08:13 make[1]: *** [dpdk-build] Error 2
12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/build-root'
12:08:13 Makefile:333: recipe for target 'build-release' failed
12:08:13 make: *** [build-release] Error 2
12:08:13 Build step 'Execute shell' marked build as failure
===

Since the MD5 checksum on the DPDK tarball fails; to answer your
question, no, it has never happened to me to see this specific issue
before.

I don't think there's anything specific to the openSUSE setup and/or
scripts being executed. I'd rather feel is - as I said earlier -
something to do with an hiccup on the infrastructure side. The fact
that a 'recheck' made it passing I suppose it confirms my current
theory.

An idea: maybe, if it happens again, we might want to ask Vanessa to
see what's the status on the slave-node? Not sure if that could give us
some more insight of what's going on.


Cheers,
Marco

On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote:
> Marco,
> 
> Can you please take a look at the build failure encountered with http
> s://gerrit.fd.io/r/#/c/9582/ on the vpp-verify-master-opensuse
> jenkins job:
> 
> - %< -
> fd.io JJB  7:56 AM
> Patch Set 2: Verified-1
> Build Failed 
> https://jenkins.fd.io/job/vpp-verify-master-opensuse/459/ : FAILURE
> No problems were identified. If you know why this problem occurred,
> please add a suitable Cause for it. ( https://jenkins.fd.io/job/vpp-v
> erify-master-opensuse/459/ )
> Logs: https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-
> master-opensuse/459
> - %< --
> 
> From the logs, it appears that there is an issue related to building
> dpdk.  Have you seen this issue before?  If so, it this an
> infrastructure issue or something else?
> 
> Thanks,
> -daw-
>  ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


Re: [vpp-dev] Papi usage example

2017-11-28 Thread Ole Troan
Holoo,

> I want to do the following vpp command with python api:
> ip route add table 1 1.2.3.4/24 10.0.0.2 GigabitEthernet2/0/1 weight 7"
> So, how can i know the name and where to find the definition of the 
> corresponding api?

ip_add_del_route in src/vnet/ip/ip.api.

Best regards,
Ole



signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] SR MPLS not effective

2017-11-28 Thread 薛欣颖

Hi Pablo,

After hearing your advice, I modified my configuration on P:

create host-interface name eth2 mac 00:0c:29:0f:e2:a8 
create host-interface name eth3 mac 00:0c:29:0f:e2:b2 
set interface state host-eth2 up 
set interface state host-eth3 up 
set interface ip address host-eth3 12.1.1.1/24 
mpls table add 0 
set interface mpls host-eth2 enable 
set interface mpls host-eth3 enable 
set interface ip address host-eth2 14.1.1.2/24 
create mpls tunnel out-label 60 via 12.1.1.2 host-eth3 
set interface state mpls-tunnel0 up 
sr mpls policy add bsid 33 next 60   //exchange the 
out-label to 60
sr mpls steer l3 23.1.1.0/24 via sr policy bsid 33
set interface mpls mpls-tunnel0 enable

the trace info on P:
00:01:54:346199: af-packet-input 
af_packet: hw_if_index 1 next-index 4 
tpacket2_hdr: 
status 0x2001 len 86 snaplen 86 mac 66 net 80 
sec 0x5a1d417b nsec 0xdffd3a9 vlan 0 
00:01:54:346226: ethernet-input 
MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8 
00:01:54:346243: mpls-input 
MPLS: next mpls-lookup[1] label 33 ttl 255 
00:01:54:346249: mpls-lookup 
MPLS: next [0], lookup fib index 0, LB index 26 hash 0 label 33 eos 0 
00:01:54:346259: error-drop 
mpls-input: MPLS DROP DPO 

The SR MPLS still not effctive. Is there any example on SR MPLS configuration?

Thanks,
Xyxue


 
From: Pablo Camarillo (pcamaril)
Date: 2017-11-28 18:16
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] SR MPLS not effective
Hi Xyxue,
 
Could you please explain what you want to achieve with this config? Where do 
you want to start your SR policy? 
None of the configs that you described below for P will work.  
 
In the case #1 you are creating a SR policy with BSID 33. Then for any packet 
with incoming label 33 you will push the SID list of the SR policy. However, 
you are also creating an mpls local-label for 33 as well which you do not need.
On top of that, you are configuring the SR policy with SID list < 60 >, but you 
have not set a local-label/route for 60. Hence packet will be dropped.
 
Thanks.
 
Cheers,
Pablo.
 
From:  on behalf of 薛欣颖 
Date: Tuesday, 28 November 2017 at 08:08
To: vpp-dev 
Subject: [vpp-dev] SR MPLS not effective
 
 
Hi guys,

I have tried every configuration I can guess. The sr mpls still not effective 
on my vpp.
Can you give me an effective configuration, or can you help figure out the 
error in my configuration?

PE1 - P - PE2

PE1 configuration:
  create host-interface name eth4 mac 00:0c:29:4d:af:b5
  create host-interface name eth2 mac 00:0c:29:4d:af:a1
  set interface state host-eth2 up
  set interface state host-eth4 up
  set interface ip table host-eth4 1
  set interface ip address host-eth2 14.1.1.1/24
  set interface ip address host-eth4 21.1.1.1/24
  create mpls tunnel out-label 33 out-label 53 via 14.1.1.2 host-eth2
  set interface state mpls-tunnel0 up
  mpls table add 0
  set interface mpls host-eth2 enable
  ip route add 23.1.1.1/24 via interface mpls-tunnel0 table 1
  mpls local-label add eos 1053 ip4-lookup-in-table 1
  mpls local-label add non-eos 1060 mpls-lookup-in-table 0

PE2 configuration:
  create host-interface name eth3 mac 00:0c:29:19:8e:76
  create host-interface name eth5 mac 00:0c:29:19:8e:8a
  set interface state host-eth3 up
  set interface state host-eth5 up
  set interface ip address host-eth3 12.1.1.2/24
  set interface ip table host-eth5 1
  set interface ip address host-eth5 23.1.1.1/24
  mpls table add 0
  mpls table add 1
  mpls local-label add non-eos 60 mpls-lookup-in-table 0
  mpls local-label add eos 53 ip4-lookup-in-table 1
  set interface mpls host-eth5 enable
  set interface mpls host-eth3 enable
  create mpls tunnel out-label 1023 out-label 1053 via 12.1.1.1 host-eth3
  set interface state mpls-tunnel0 up
  ip route add 21.1.1.0/24 via interface mpls-tunnel0 table 1
  
P configuration:
(only modify the configuration on P)
1. drop packet.(when decap outer label,can't encap outer label) the 
configuration and trace is following:
 create host-interface name eth2 mac 00:0c:29:0f:e2:a8
  create host-interface name eth3 mac 00:0c:29:0f:e2:b2
  set interface state host-eth2 up
  set interface state host-eth3 up
  set interface ip address host-eth3 12.1.1.1/24
  mpls table add 0
  mpls table add 1
  set interface mpls host-eth2 enable
  set interface mpls host-eth3 enable
  mpls local-label add non-eos 33 mpls-lookup-in-table 0
  set interface ip address host-eth2 14.1.1.2/24
  mpls local-label add eos 53 ip4-lookup-in-table 0
  mpls local-label add eos 1053 ip4-lookup-in-table 0
  mpls local-label add non-eos 1023 mpls-lookup-in-table 0
  sr mpls policy add bsid 33 next 60
  
  00:08:35:510564: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x2001 len 86 snaplen 86 mac 66 net 80
  sec 0x5a1cbe94 nsec 0x1ea50e69 vlan 0
00:08:35:510591: ethernet-input
  MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8
00:08:35:510650: 

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

2017-11-28 Thread Marco Varlese
Hi Gabriel,
On Tue, 2017-11-28 at 10:13 +, Gabriel Ganne wrote:
> Hi Marco,
> 
> 
> 
> 
> 
> I believe 
> http://fast.dpdk.org/rel redirects to 
> http://static.dpdk.org/rel/
> 
> 
> 
> 
> 
> 
> 
> I disagree on the md5 hashs.
> 
> I have the following (NOK on 17.08, and OK on 17.11) :
> 
> 
> 
> 
> 
> 
> 
> $ wget 
> http://static.dpdk.org/rel/dpdk-17.08.tar.xz
> 
> 
> 
> $ openssl md5 dpdk-17.08.tar.xz
> # is 0641f59ea8ea98afefa7cfa2699f6241 in dpdk/Makefile
> 
> 
> 
> MD5(dpdk-17.08.tar.xz)= 537ff038915fefd0f210905fafcadb4b
> 
Ah, when I said correct, I said it according to the DPDK.org web-site page http:
//dpdk.org/rel which apperently shows an MD5 for 17.08 equal to the one we use
currently in VPP... :(
> 
> 
> 
> $ wget 
> http://static.dpdk.org/rel/dpdk-17.11.tar.xz
> 
> 
> $ openssl md5 dpdk-17.11.tar.xz
> 
> 
> MD5(dpdk-17.11.tar.xz)= 53ee9e054a8797c9e67ffa0eb5d0c701
> 
> 
> 
> 
> 
> 
> Though I agree that if the "recheck" button made the build pass, there must be
> something wrong on my side.
> 
> 
>  ... what did I miss ?
> 
> 
> 
> 
> 
> 
> 
> --
> 
> 
> Gabriel Ganne
> 
> 
> 
> 
> 
> 
> From: Marco Varlese 
> 
> Sent: Tuesday, November 28, 2017 10:55:49 AM
> 
> To: Gabriel Ganne; Dave Wallace; Gonzalez Monroy, Sergio
> 
> Cc: vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
>  
> 
> 
> 
> 
> 
> Hi Gabriel,
> 
> 
> 
> On Tue, 2017-11-28 at 09:19 +, Gabriel Ganne wrote:
> > Hi,
> > 
> > 
> > 
> > I also have this issue on my machine, and I see on
> > 
> > http://static.dpdk.org/rel/ that dpdk-17.08.tar.xz  was written yesterday
> > (27-Nov-2017 13:00)
> > Wouldn't it be possible that the archive was overwritten ?
> > 
> 
> The DPDK tarball in VPP is downloaded from 
> http://fast.dpdk.org/rel 
> According to 
> http://dpdk.org/rel the MD5 used in VPP for the DPDK 17.08 release is correct.
> > 
> > 
> > 
> > In which case, the hash would need to be updated.
> > 
> > 
> > 
> 
> Right, if the tarball was a newer and different one then the MD5 hash should
> be updated in VPP for the the checksum performed...
> However, in the case described by Dave below, a simple 'recheck' which
> triggers a new build (with the same code/scripts/etc. hence the same MD5 hash)
> solved it.
> 
> 
> 
> > 
> > Also, this would probably not be seen by people who had the 
> > dpdk-install-dev 
> > package already installed.
> > 
> > 
> > 
> > 
> > 
> > Who should I ask to check this ?
> > 
> > 
> > 
> 
> I've added Sergio who might have further thoughts on this one.
> 
> 
> 
> > 
> > 
> > 
> > 
> > Best regards
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > 
> > 
> > Gabriel Ganne
> > 
> > 
> > 
> > 
> > 
> > From: vpp-dev-boun...@lists.fd.io  on behalf of
> > Marco Varlese 
> > 
> > Sent: Tuesday, November 28, 2017 9:19:37 AM
> > 
> > To: Dave Wallace
> > 
> > Cc: vpp-dev@lists.fd.io
> > 
> > Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
> >  
> > 
> > 
> > Dear Dave,
> > 
> > 
> > 
> > By the look of it is seemed to have been an hiccup with the download or
> > 
> > that something spurious was left on the filesystem...
> > 
> > ===
> > 
> > 12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
> > 
> > opensuse/dpdk/dpdk-17.08.tar.xz and retry
> > 
> > 12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
> > 
> > master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
> > 
> > 12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
> > 
> > root/build-vpp-native/dpdk/.download.ok] Error 1
> > 
> > 12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
> > 
> > opensuse/dpdk'
> > 
> > 12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
> > 
> > 12:08:13 make[2]: *** [ebuild-build] Error 2
> > 
> > 12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
> > 
> > opensuse/dpdk'
> > 
> > 12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
> > 
> > 12:08:13 make[1]: *** [dpdk-build] Error 2
> > 
> > 12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
> > 
> > opensuse/build-root'
> > 
> > 12:08:13 Makefile:333: recipe for target 'build-release' failed
> > 
> > 12:08:13 make: *** [build-release] Error 2
> > 
> > 12:08:13 Build step 'Execute shell' marked build as failure
> > 
> > ===
> > 
> > 
> > 
> > Since the MD5 checksum on the DPDK tarball fails; to answer your
> > 
> > question, no, it has never happened to me to see this specific issue
> > 
> > before.
> > 
> > 
> > 
> > I don't think there's anything specific to the openSUSE setup and/or
> > 
> > scripts being executed. I'd rather feel is - as I said earlier -
> > 
> > something to do with an hiccup on the infrastructure side. The fact
> > 
> > that a 'recheck' made it passing I suppose it confirms my current
> > 
> > theory.
> > 
> > 
> > 
> > An idea: maybe, if it happens again, we might want to ask 

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

2017-11-28 Thread Gabriel Ganne
Adding dpdk-user ML.


I had a look with an older dpdk archive I found.

The folder archived has been renamed from *dpdk-17.08* to *dpdk-stable-17.08*

This is the only difference, but it is enough to make the md5sum fail.


--

Gabriel Ganne


From: Gabriel Ganne
Sent: Tuesday, November 28, 2017 11:13:23 AM
To: Marco Varlese; Dave Wallace; Gonzalez Monroy, Sergio
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage


Hi Marco,


I believe http://fast.dpdk.org/rel redirects to http://static.dpdk.org/rel/


I disagree on the md5 hashs.

I have the following (NOK on 17.08, and OK on 17.11) :


$ wget http://static.dpdk.org/rel/dpdk-17.08.tar.xz

$ openssl md5 dpdk-17.08.tar.xz # is 0641f59ea8ea98afefa7cfa2699f6241 in 
dpdk/Makefile

MD5(dpdk-17.08.tar.xz)= 537ff038915fefd0f210905fafcadb4b


$ wget http://static.dpdk.org/rel/dpdk-17.11.tar.xz

$ openssl md5 dpdk-17.11.tar.xz

MD5(dpdk-17.11.tar.xz)= 53ee9e054a8797c9e67ffa0eb5d0c701


Though I agree that if the "recheck" button made the build pass, there must be 
something wrong on my side.

 ... what did I miss ?


--

Gabriel Ganne


From: Marco Varlese 
Sent: Tuesday, November 28, 2017 10:55:49 AM
To: Gabriel Ganne; Dave Wallace; Gonzalez Monroy, Sergio
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

Hi Gabriel,

On Tue, 2017-11-28 at 09:19 +, Gabriel Ganne wrote:

Hi,


I also have this issue on my machine, and I see on 
http://static.dpdk.org/rel/
 that dpdk-17.08.tar.xz  was written yesterday (27-Nov-2017 13:00)

Wouldn't it be possible that the archive was overwritten ?

The DPDK tarball in VPP is downloaded from 
http://fast.dpdk.org/rel
According to 
http://dpdk.org/rel
 the MD5 used in VPP for the DPDK 17.08 release is correct.


In which case, the hash would need to be updated.

Right, if the tarball was a newer and different one then the MD5 hash should be 
updated in VPP for the the checksum performed...
However, in the case described by Dave below, a simple 'recheck' which triggers 
a new build (with the same code/scripts/etc. hence the same MD5 hash) solved it.


Also, this would probably not be seen by people who had the dpdk-install-dev 
package already installed.


Who should I ask to check this ?

I've added Sergio who might have further thoughts on this one.



Best regards


--

Gabriel Ganne

From: vpp-dev-boun...@lists.fd.io  on behalf of 
Marco Varlese 
Sent: Tuesday, November 28, 2017 9:19:37 AM
To: Dave Wallace
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

Dear Dave,

By the look of it is seemed to have been an hiccup with the download or
that something spurious was left on the filesystem...
===
12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
opensuse/dpdk/dpdk-17.08.tar.xz and retry
12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
root/build-vpp-native/dpdk/.download.ok] Error 1
12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
12:08:13 make[2]: *** [ebuild-build] Error 2
12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
12:08:13 make[1]: *** [dpdk-build] Error 2
12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/build-root'
12:08:13 Makefile:333: recipe for target 'build-release' failed
12:08:13 make: *** [build-release] Error 2
12:08:13 Build step 'Execute shell' marked build as failure
===

Since the MD5 checksum on the DPDK tarball fails; to answer your
question, no, it has never happened to me to see this specific issue
before.

I don't think there's anything specific to the openSUSE setup and/or
scripts being executed. I'd rather 

Re: [vpp-dev] SR MPLS not effective

2017-11-28 Thread Pablo Camarillo (pcamaril)
Hi Xyxue,

Could you please explain what you want to achieve with this config? Where do 
you want to start your SR policy?
None of the configs that you described below for P will work.

In the case #1 you are creating a SR policy with BSID 33. Then for any packet 
with incoming label 33 you will push the SID list of the SR policy. However, 
you are also creating an mpls local-label for 33 as well which you do not need.
On top of that, you are configuring the SR policy with SID list < 60 >, but you 
have not set a local-label/route for 60. Hence packet will be dropped.

Thanks.

Cheers,
Pablo.

From:  on behalf of 薛欣颖 
Date: Tuesday, 28 November 2017 at 08:08
To: vpp-dev 
Subject: [vpp-dev] SR MPLS not effective


Hi guys,

I have tried every configuration I can guess. The sr mpls still not effective 
on my vpp.
Can you give me an effective configuration, or can you help figure out the 
error in my configuration?

PE1 - P - PE2

PE1 configuration:
  create host-interface name eth4 mac 00:0c:29:4d:af:b5
  create host-interface name eth2 mac 00:0c:29:4d:af:a1
  set interface state host-eth2 up
  set interface state host-eth4 up
  set interface ip table host-eth4 1
  set interface ip address host-eth2 14.1.1.1/24
  set interface ip address host-eth4 21.1.1.1/24
  create mpls tunnel out-label 33 out-label 53 via 14.1.1.2 host-eth2
  set interface state mpls-tunnel0 up
  mpls table add 0
  set interface mpls host-eth2 enable
  ip route add 23.1.1.1/24 via interface mpls-tunnel0 table 1
  mpls local-label add eos 1053 ip4-lookup-in-table 1
  mpls local-label add non-eos 1060 mpls-lookup-in-table 0

PE2 configuration:
  create host-interface name eth3 mac 00:0c:29:19:8e:76
  create host-interface name eth5 mac 00:0c:29:19:8e:8a
  set interface state host-eth3 up
  set interface state host-eth5 up
  set interface ip address host-eth3 12.1.1.2/24
  set interface ip table host-eth5 1
  set interface ip address host-eth5 23.1.1.1/24
  mpls table add 0
  mpls table add 1
  mpls local-label add non-eos 60 mpls-lookup-in-table 0
  mpls local-label add eos 53 ip4-lookup-in-table 1
  set interface mpls host-eth5 enable
  set interface mpls host-eth3 enable
  create mpls tunnel out-label 1023 out-label 1053 via 12.1.1.1 host-eth3
  set interface state mpls-tunnel0 up
  ip route add 21.1.1.0/24 via interface mpls-tunnel0 table 1

P configuration:
(only modify the configuration on P)
1. drop packet.(when decap outer label,can't encap outer label) the 
configuration and trace is following:
 create host-interface name eth2 mac 00:0c:29:0f:e2:a8
  create host-interface name eth3 mac 00:0c:29:0f:e2:b2
  set interface state host-eth2 up
  set interface state host-eth3 up
  set interface ip address host-eth3 12.1.1.1/24
  mpls table add 0
  mpls table add 1
  set interface mpls host-eth2 enable
  set interface mpls host-eth3 enable
  mpls local-label add non-eos 33 mpls-lookup-in-table 0
  set interface ip address host-eth2 14.1.1.2/24
  mpls local-label add eos 53 ip4-lookup-in-table 0
  mpls local-label add eos 1053 ip4-lookup-in-table 0
  mpls local-label add non-eos 1023 mpls-lookup-in-table 0
  sr mpls policy add bsid 33 next 60

  00:08:35:510564: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x2001 len 86 snaplen 86 mac 66 net 80
  sec 0x5a1cbe94 nsec 0x1ea50e69 vlan 0
00:08:35:510591: ethernet-input
  MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8
00:08:35:510650: mpls-input
  MPLS: next mpls-lookup[1]  label 33 ttl 255
00:08:35:510657: mpls-lookup
  MPLS: next [0], lookup fib index 0, LB index 26 hash 0 label 33 eos 0
00:08:35:510666: error-drop
  mpls-input: MPLS DROP DPO

2.replace 'sr mpls policy add bsid 33 next 60' with 'sr mpls policy add bsid 
4001 next 60'. the trace info is following:
00:15:38:655991: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x2001 len 86 snaplen 86 mac 66 net 80
  sec 0x5a1cc03b nsec 0x1225fbd8 vlan 0
00:15:38:656023: ethernet-input
  MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8
00:15:38:656089: mpls-input
  MPLS: next mpls-lookup[1]  label 33 ttl 255
00:15:38:656100: mpls-lookup
  MPLS: next [6], lookup fib index 0, LB index 26 hash 0 label 33 eos 0
00:15:38:656130: lookup-mpls-dst
 fib-index:0 hdr:[53:255:0:eos] load-balance:31
00:15:38:656137: ip4-mpls-label-disposition
  disp:0
00:15:38:656144: lookup-ip4-dst
 fib-index:0 addr:23.1.1.5 load-balance:1
00:15:38:656151: ip4-drop
ICMP: 21.1.1.5 -> 23.1.1.5
  tos 0x00, ttl 63, length 64, checksum 0x4db1
  fragment id 0x0001
ICMP echo_request checksum 0x5f5d
00:15:38:656160: error-drop
  ip4-mpls-label-disposition: valid ip4 packets

3.add the mpls tunnel configuration, remove static routing configuration, the 
configuration and trace is following:
create host-interface name eth2 mac 00:0c:29:0f:e2:a8
  create host-interface name eth3 mac 

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

2017-11-28 Thread Gabriel Ganne
Hi Marco,


I believe http://fast.dpdk.org/rel redirects to http://static.dpdk.org/rel/


I disagree on the md5 hashs.

I have the following (NOK on 17.08, and OK on 17.11) :


$ wget http://static.dpdk.org/rel/dpdk-17.08.tar.xz

$ openssl md5 dpdk-17.08.tar.xz # is 0641f59ea8ea98afefa7cfa2699f6241 in 
dpdk/Makefile

MD5(dpdk-17.08.tar.xz)= 537ff038915fefd0f210905fafcadb4b


$ wget http://static.dpdk.org/rel/dpdk-17.11.tar.xz

$ openssl md5 dpdk-17.11.tar.xz

MD5(dpdk-17.11.tar.xz)= 53ee9e054a8797c9e67ffa0eb5d0c701


Though I agree that if the "recheck" button made the build pass, there must be 
something wrong on my side.

 ... what did I miss ?


--

Gabriel Ganne


From: Marco Varlese 
Sent: Tuesday, November 28, 2017 10:55:49 AM
To: Gabriel Ganne; Dave Wallace; Gonzalez Monroy, Sergio
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

Hi Gabriel,

On Tue, 2017-11-28 at 09:19 +, Gabriel Ganne wrote:

Hi,


I also have this issue on my machine, and I see on 
http://static.dpdk.org/rel/
 that dpdk-17.08.tar.xz  was written yesterday (27-Nov-2017 13:00)

Wouldn't it be possible that the archive was overwritten ?

The DPDK tarball in VPP is downloaded from 
http://fast.dpdk.org/rel
According to 
http://dpdk.org/rel
 the MD5 used in VPP for the DPDK 17.08 release is correct.


In which case, the hash would need to be updated.

Right, if the tarball was a newer and different one then the MD5 hash should be 
updated in VPP for the the checksum performed...
However, in the case described by Dave below, a simple 'recheck' which triggers 
a new build (with the same code/scripts/etc. hence the same MD5 hash) solved it.


Also, this would probably not be seen by people who had the dpdk-install-dev 
package already installed.


Who should I ask to check this ?

I've added Sergio who might have further thoughts on this one.



Best regards


--

Gabriel Ganne

From: vpp-dev-boun...@lists.fd.io  on behalf of 
Marco Varlese 
Sent: Tuesday, November 28, 2017 9:19:37 AM
To: Dave Wallace
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

Dear Dave,

By the look of it is seemed to have been an hiccup with the download or
that something spurious was left on the filesystem...
===
12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
opensuse/dpdk/dpdk-17.08.tar.xz and retry
12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
root/build-vpp-native/dpdk/.download.ok] Error 1
12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
12:08:13 make[2]: *** [ebuild-build] Error 2
12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
12:08:13 make[1]: *** [dpdk-build] Error 2
12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/build-root'
12:08:13 Makefile:333: recipe for target 'build-release' failed
12:08:13 make: *** [build-release] Error 2
12:08:13 Build step 'Execute shell' marked build as failure
===

Since the MD5 checksum on the DPDK tarball fails; to answer your
question, no, it has never happened to me to see this specific issue
before.

I don't think there's anything specific to the openSUSE setup and/or
scripts being executed. I'd rather feel is - as I said earlier -
something to do with an hiccup on the infrastructure side. The fact
that a 'recheck' made it passing I suppose it confirms my current
theory.

An idea: maybe, if it happens again, we might want to ask Vanessa to
see what's the status on the slave-node? Not sure if that could give us
some more insight of what's going on.


Cheers,
Marco

On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote:
> Marco,
>
> Can you please take a look at the build failure encountered 

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

2017-11-28 Thread Marco Varlese
Hi Gabriel,
On Tue, 2017-11-28 at 09:19 +, Gabriel Ganne wrote:
> Hi,
> 
> 
> 
> 
> 
> I also have this issue on my machine, and I see on
> 
> http://static.dpdk.org/rel/ that dpdk-17.08.tar.xz  was written yesterday (27-
> Nov-2017 13:00)
> 
> Wouldn't it be possible that the archive was overwritten ?
The DPDK tarball in VPP is downloaded from http://fast.dpdk.org/rel According to
http://dpdk.org/rel the MD5 used in VPP for the DPDK 17.08 release
is correct.
> 
> 
> 
> In which case, the hash would need to be updated.
Right, if the tarball was a newer and different one then the MD5 hash should be
updated in VPP for the the checksum performed...However, in the case described
by Dave below, a simple 'recheck' which triggers a new build (with the same
code/scripts/etc. hence the same MD5 hash) solved it.
> 
> Also, this would probably not be seen by people who had the dpdk-install-dev
> package already installed.
> 
> 
> 
> 
> 
> 
> 
> Who should I ask to check this ?
I've added Sergio who might have further thoughts on this one.
> 
> 
> 
> Best regards
> 
> 
> 
> 
> 
> 
> 
> --
> 
> 
> Gabriel Ganne
> 
> 
> 
> 
> 
> 
> From: vpp-dev-boun...@lists.fd.io  on behalf of
> Marco Varlese 
> 
> Sent: Tuesday, November 28, 2017 9:19:37 AM
> 
> To: Dave Wallace
> 
> Cc: vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
>  
> 
> 
> Dear Dave,
> 
> 
> 
> By the look of it is seemed to have been an hiccup with the download or
> 
> that something spurious was left on the filesystem...
> 
> ===
> 
> 12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
> 
> opensuse/dpdk/dpdk-17.08.tar.xz and retry
> 
> 12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
> 
> master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
> 
> 12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
> 
> root/build-vpp-native/dpdk/.download.ok] Error 1
> 
> 12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
> 
> opensuse/dpdk'
> 
> 12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
> 
> 12:08:13 make[2]: *** [ebuild-build] Error 2
> 
> 12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
> 
> opensuse/dpdk'
> 
> 12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
> 
> 12:08:13 make[1]: *** [dpdk-build] Error 2
> 
> 12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
> 
> opensuse/build-root'
> 
> 12:08:13 Makefile:333: recipe for target 'build-release' failed
> 
> 12:08:13 make: *** [build-release] Error 2
> 
> 12:08:13 Build step 'Execute shell' marked build as failure
> 
> ===
> 
> 
> 
> Since the MD5 checksum on the DPDK tarball fails; to answer your
> 
> question, no, it has never happened to me to see this specific issue
> 
> before.
> 
> 
> 
> I don't think there's anything specific to the openSUSE setup and/or
> 
> scripts being executed. I'd rather feel is - as I said earlier -
> 
> something to do with an hiccup on the infrastructure side. The fact
> 
> that a 'recheck' made it passing I suppose it confirms my current
> 
> theory.
> 
> 
> 
> An idea: maybe, if it happens again, we might want to ask Vanessa to
> 
> see what's the status on the slave-node? Not sure if that could give us
> 
> some more insight of what's going on.
> 
> 
> 
> 
> 
> Cheers,
> 
> Marco
> 
> 
> 
> On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote:
> 
> > Marco,
> 
> > 
> 
> > Can you please take a look at the build failure encountered with http
> 
> > s://gerrit.fd.io/r/#/c/9582/ on the vpp-verify-master-opensuse
> 
> > jenkins job:
> 
> > 
> 
> > - %< -
> 
> > fd.io JJB  7:56 AM
> 
> > Patch Set 2: Verified-1
> 
> > Build Failed 
> 
> > https://jenkins.fd.io/job/vpp-verify-master-opensuse/459/ : FAILURE
> 
> > No problems were identified. If you know why this problem occurred,
> 
> > please add a suitable Cause for it. ( 
> https://jenkins.fd.io/job/vpp-v
> 
> > erify-master-opensuse/459/ )
> 
> > Logs: 
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-
> 
> > master-opensuse/459
> 
> > - %< --
> 
> > 
> 
> > From the logs, it appears that there is an issue related to building
> 
> > dpdk.  Have you seen this issue before?  If so, it this an
> 
> > infrastructure issue or something else?
> 
> > 
> 
> > Thanks,
> 
> > -daw-
> 
> >  ___
> 
> > vpp-dev mailing list
> 
> > vpp-dev@lists.fd.io
> 
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> ___
> 
> vpp-dev mailing list
> 
> vpp-dev@lists.fd.io
> 
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> 
> 
> 
> 
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg___
vpp-dev mailing list
vpp-dev@lists.fd.io

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

2017-11-28 Thread Gabriel Ganne
Hi,


I also have this issue on my machine, and I see on http://static.dpdk.org/rel/ 
that dpdk-17.08.tar.xz  was written yesterday (27-Nov-2017 13:00)

Wouldn't it be possible that the archive was overwritten ?


In which case, the hash would need to be updated.

Also, this would probably not be seen by people who had the dpdk-install-dev 
package already installed.


Who should I ask to check this ?


Best regards


--

Gabriel Ganne


From: vpp-dev-boun...@lists.fd.io  on behalf of 
Marco Varlese 
Sent: Tuesday, November 28, 2017 9:19:37 AM
To: Dave Wallace
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

Dear Dave,

By the look of it is seemed to have been an hiccup with the download or
that something spurious was left on the filesystem...
===
12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
opensuse/dpdk/dpdk-17.08.tar.xz and retry
12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
root/build-vpp-native/dpdk/.download.ok] Error 1
12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
12:08:13 make[2]: *** [ebuild-build] Error 2
12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
12:08:13 make[1]: *** [dpdk-build] Error 2
12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/build-root'
12:08:13 Makefile:333: recipe for target 'build-release' failed
12:08:13 make: *** [build-release] Error 2
12:08:13 Build step 'Execute shell' marked build as failure
===

Since the MD5 checksum on the DPDK tarball fails; to answer your
question, no, it has never happened to me to see this specific issue
before.

I don't think there's anything specific to the openSUSE setup and/or
scripts being executed. I'd rather feel is - as I said earlier -
something to do with an hiccup on the infrastructure side. The fact
that a 'recheck' made it passing I suppose it confirms my current
theory.

An idea: maybe, if it happens again, we might want to ask Vanessa to
see what's the status on the slave-node? Not sure if that could give us
some more insight of what's going on.


Cheers,
Marco

On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote:
> Marco,
>
> Can you please take a look at the build failure encountered with http
> s://gerrit.fd.io/r/#/c/9582/ on the vpp-verify-master-opensuse
> jenkins job:
>
> - %< -
> fd.io JJB  7:56 AM
> Patch Set 2: Verified-1
> Build Failed
> https://jenkins.fd.io/job/vpp-verify-master-opensuse/459/ : FAILURE
> No problems were identified. If you know why this problem occurred,
> please add a suitable Cause for it. ( https://jenkins.fd.io/job/vpp-v
> erify-master-opensuse/459/ )
> Logs: https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-
> master-opensuse/459
> - %< --
>
> From the logs, it appears that there is an issue related to building
> dpdk.  Have you seen this issue before?  If so, it this an
> infrastructure issue or something else?
>
> Thanks,
> -daw-
>  ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev