Good: I have a direction where to look into.
The patch does not help me.

Yet, switching from
cpu {
  main-core 0
  corelist-workers 3,7
}

To
cpu {
  main-core 1
#  corelist-workers 3,7
}

Hides the problem.

As soon as I enable the corelist-workers (event with continuous workers, main 
core 1, core-list 2-3) I do have an exception.
Christophe

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Christophe FONTAINE
Sent: mercredi 30 novembre 2016 08:16
To: Damjan Marion <dmarion.li...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] How to transfer packets between 2 bridge domains ?

Thanks, I’ll try it and get back to you ☺

Christophe

From: Damjan Marion [mailto:dmarion.li...@gmail.com]
Sent: mardi 29 novembre 2016 23:11
To: Christophe FONTAINE 
<christophe.fonta...@qosmos.com<mailto:christophe.fonta...@qosmos.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] How to transfer packets between 2 bridge domains ?

Hi Christophe,

This one might help you:

https://git.fd.io/vpp/commit/?id=e2e95ce6550a28a6ba5870c9c550acb619883f1a

Thanks,

Damjan

On 29 Nov 2016, at 12:24, Christophe FONTAINE 
<christophe.fonta...@qosmos.com<mailto:christophe.fonta...@qosmos.com>> wrote:

I just did the test with the same platform (I added another intel NIC), same 
problem (assert on VLIB_FRAME_IS_ALLOCATED) in debug.
And so, I got an identical backtrace.
# set int span GigabitEthernet8/0/0 destination GigabitEthernet3/0/0

Christophe

-----Original Message-----
From: Damjan Marion [mailto:dmarion.li...@gmail.com]
Sent: lundi 28 novembre 2016 21:57
To: Christophe FONTAINE 
<christophe.fonta...@qosmos.com<mailto:christophe.fonta...@qosmos.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] How to transfer packets between 2 bridge domains ?


Have you tried with different physical interfaces used for source and mirror?

On 28 Nov 2016, at 19:33, Christophe Fontaine
<christophe.fonta...@qosmos.com<mailto:christophe.fonta...@qosmos.com>> wrote:

Hi,

I do have a span 1-N working patch, but I also do have some bugs on
the frame allocation (I think).

I was able to reproduce the same bugs with the 1-1 span node (ie
without any patch on my side).

Setup:

vpp# create sub-interface GigabitEthernet8/0/0 442 vpp# set int span
GigabitEthernet8/0/0 destination GigabitEthernet8/0/0.442 vpp# set int
state GigabitEthernet8/0/0 up vpp# set int state
GigabitEthernet8/0/0.442 up


From there, I send some packets with scapy (and I receive the copy on
the appropriate VLAN ) scapy # while True:
sendp(Ether(dst='00:1b:21:6f:27:b6')/IP(dst='255.255.255.255')/ICMP(),
iface='enp1s0f0', count=200)


Not so many packets at once, but that's enough to have 2 asserts which
raised, whithout being deterministic (backtraces below)
- VLIB_FRAME_IS_ALLOCATED
- VLIB_FRAME_PENDING

My vpp configuration file is the following:
heapsize 2G
cpu {
main-core 0
corelist-workers 3,7
}

dpdk {
  socket-mem 1024
  uio-driver uio_pci_generic
  dev 0000:08:00.0
}


Where can I dig a bit more and resolve these bugs ?
Thanks,
Christophe


#0  0x00007ffff51945f7 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff5195ce8 in __GI_abort () at abort.c:90
#2  0x0000000000c2c135 in os_panic () at
/root/vpp/build-data/../vpp/vnet/main.c:314
#3  0x00007ffff605a984 in debugger () at
/root/vpp/build-data/../vppinfra/vppinfra/error.c:84
#4  0x00007ffff605ad8b in _clib_error (how_to_die=2,
function_name=0x0, line_number=0, fmt=0x7ffff7542160 "%s:%d (%s)
assertion `%s' fails") at
/root/vpp/build-data/../vppinfra/vppinfra/error.c:143
#5  0x00007ffff74e949a in vlib_get_frame (vm=0x1244c80
<vlib_global_main>, frame_index=20599040) at
/root/vpp/build-data/../vlib/vlib/node_funcs.h:226
#6  0x00007ffff74ecfa8 in dispatch_pending_node (vm=0x1244c80
<vlib_global_main>, p=0x7fff762cf118,
last_time_stamp=25415901095678999)
at /root/vpp/build-data/../vlib/vlib/main.c:1099
#7  0x00007ffff74ef0ff in vlib_main_loop (vm=0x1244c80
<vlib_global_main>) at /root/vpp/build-data/../vlib/vlib/main.c:1543
#8  0x00007ffff74ef77d in vlib_main (vm=0x1244c80 <vlib_global_main>,
input=0x7fff75149fb0) at /root/vpp/build-data/../vlib/vlib/main.c:1678
#9  0x00007ffff7780b0c in thread0 (arg=19156096) at
/root/vpp/build-data/../vlib/vlib/unix/main.c:485
#10 0x00007ffff607ec30 in clib_calljmp () at
/root/vpp/build-data/../vppinfra/vppinfra/longjmp.S:110
#11 0x00007fffffffcec0 in ?? ()
#12 0x00007ffff7780f6c in vlib_unix_main (argc=41,
argv=0x7fffffffe178) at
/root/vpp/build-data/../vlib/vlib/unix/main.c:545
#13 0x0000000000c2be16 in main (argc=41, argv=0x7fffffffe178) at
/root/vpp/build-data/../vpp/vnet/main.c:255


frame 5:

#5  0x00007ffff74e949a in vlib_get_frame (vm=0x1244c80
<vlib_global_main>, frame_index=20599040) at
/root/vpp/build-data/../vlib/vlib/node_funcs.h:226
226       ASSERT (f->flags & VLIB_FRAME_IS_ALLOCATED);





And here is the other one:

(gdb) bt
#0  0x00007ffff51945f7 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff5195ce8 in __GI_abort () at abort.c:90
#2  0x0000000000c2c135 in os_panic () at
/root/vpp/build-data/../vpp/vnet/main.c:314
#3  0x00007ffff605a984 in debugger () at
/root/vpp/build-data/../vppinfra/vppinfra/error.c:84
#4  0x00007ffff605ad8b in _clib_error (how_to_die=2,
function_name=0x0, line_number=0, fmt=0x7ffff7542160 "%s:%d (%s)
assertion `%s' fails") at
/root/vpp/build-data/../vppinfra/vppinfra/error.c:143
#5  0x00007ffff74ed174 in dispatch_pending_node (vm=0x1244c80
<vlib_global_main>, p=0x7fff762c9470,
last_time_stamp=25416170327760415)
at /root/vpp/build-data/../vlib/vlib/main.c:1124
#6  0x00007ffff74ef0ff in vlib_main_loop (vm=0x1244c80
<vlib_global_main>) at /root/vpp/build-data/../vlib/vlib/main.c:1543
#7  0x00007ffff74ef77d in vlib_main (vm=0x1244c80 <vlib_global_main>,
input=0x7fff75149fb0) at /root/vpp/build-data/../vlib/vlib/main.c:1678
#8  0x00007ffff7780b0c in thread0 (arg=19156096) at
/root/vpp/build-data/../vlib/vlib/unix/main.c:485
#9  0x00007ffff607ec30 in clib_calljmp () at
/root/vpp/build-data/../vppinfra/vppinfra/longjmp.S:110
#10 0x00007fffffffcec0 in ?? ()
#11 0x00007ffff7780f6c in vlib_unix_main (argc=41,
argv=0x7fffffffe178) at
/root/vpp/build-data/../vlib/vlib/unix/main.c:545
#12 0x0000000000c2be16 in main (argc=41, argv=0x7fffffffe178) at
/root/vpp/build-data/../vpp/vnet/main.c:255


#5  0x00007ffff74ed174 in dispatch_pending_node (vm=0x1244c80
<vlib_global_main>, p=0x7fff762c9470,
last_time_stamp=25416170327760415)
at /root/vpp/build-data/../vlib/vlib/main.c:1124
1124      ASSERT (f->flags & VLIB_FRAME_PENDING);







On 11/25/2016 02:21 PM, Christophe FONTAINE wrote:
Yes, I think so.
I'll give it a try and modify the span node.

Christophe

PS: I have modified the l2patch feature to also support the connection on
the tx side, if anyone is interested, I can submit it.

Here is the journey of a packet sent with scapy on the vlan 442,
getting flooded on the 1st bd, sent to the other bd, and Sent back
with the appropriate vlan (443)


00:19:55:173391: dpdk-input
 GigabitEthernet8/0/0 rx queue 0
 buffer 0x5727: current data 0, length 60, free-list 0, totlen-nifb 0, trace
0x60
 PKT MBUF: port 0, nb_segs 1, pkt_len 60
   buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr
0xfd721fc0
   packet_type 0x0
 ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 442
 request, type ethernet/IP4, address size 6/4
 78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0
00:19:55:173394: ethernet-input
 ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 442
00:19:55:173398: l2-input
 l2-input: sw_if_index 2 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00
00:19:55:173400: l2-input-vtr
 l2-input-vtr: sw_if_index 2 dst 28:94:0f:fe:00:40 src
00:00:00:00:00:00 data 08 06 00 01 08 00 06 04 00 01 78 24
00:19:55:173401: l2-flood
 l2-flood: sw_if_index 2 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00
bd_index 1
00:19:55:173403: l2-output
 l2-output: sw_if_index 4 dst 28:94:0f:fe:00:40 src
00:00:00:00:00:00
00:19:55:173404: l2-patch
 L2_PATCH: rx 2 tx 5
00:19:55:173405: loop1-output
 loop1
 ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40
 request, type ethernet/IP4, address size 6/4
 78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0
00:19:55:173410: ethernet-input
 ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40
00:19:55:173411: l2-input
 l2-input: sw_if_index 5 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00
00:19:55:173413: l2-flood
 l2-flood: sw_if_index 5 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00
bd_index 2
00:19:55:173414: l2-output
 l2-output: sw_if_index 3 dst 28:94:0f:fe:00:40 src
00:00:00:00:00:00
00:19:55:173415: GigabitEthernet8/0/0-output
 GigabitEthernet8/0/0.443
 ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 443
 request, type ethernet/IP4, address size 6/4
 78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0
00:19:55:173416: GigabitEthernet8/0/0-tx
 GigabitEthernet8/0/0 tx queue 1
 buffer 0x5727: current data 0, length 60, free-list 0, totlen-nifb 0, trace
0x60
 ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 443
 request, type ethernet/IP4, address size 6/4
 78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0

-----Original Message-----
From: Damjan Marion [mailto:dmarion.li...@gmail.com]
Sent: vendredi 25 novembre 2016 14:12
To: Christophe FONTAINE 
<christophe.fonta...@qosmos.com<mailto:christophe.fonta...@qosmos.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] How to transfer packets between 2 bridge
domains ?


Is this something which can be solved simply by telling to span node
to have multiple destination interfaces?

On 24 Nov 2016, at 20:22, Christophe FONTAINE
<christophe.fonta...@qosmos.com<mailto:christophe.fonta...@qosmos.com>> wrote:

Hi,

I’m working on Tap as a Service feature for OpenStack [1], and I
hope I just
don’t know how to configure VPP to transfer packets between 2 bridge
domains.
The global setup follows the blueprint [2], but basically, here is
what I have
:

VhostUser0/0/1
 |
span
 |
loop0               loop1
 |                           |
[BD-A] === [BD-B]--VhostUser0/0/2
                              |
                         Gigabit/0/0/1.3901

Booth bridge domains are configured to flood the traffic.
This 2 bridge domain setup is required to be able to have the
traffic from1
spanned interface (named tap-flow) copied to multiple destination
(named tap-service), as well as multiple tap-flows to a single tap-service.

The problem I have is that I can't use 2 loopback interfaces with a
cross
connect because the xconnect feature:
- is tied to the device-input feature mask: when incoming packets
are flooded by the bridge, the packets are sent to interface-out,
and to not go thru the rx path
- as it is tied to the device-input feature mask, we can't have
xconnect AND
bridge features enabled at the same time.
Same problem with the l2patch.

I tried different things, such as using the input and output
classifiers to
redirect packets to the appropriate interface-out  (eg: loop2-tx
)nodes, using the same vhost user socket as client and server to
loopback the traffic from 2 bridge domains, using 2 sub-interfaces
from a loopback interface to transfer the packets from 1 bd to the
other, but I think I'm missing something important !
The only way I got this working was by using an external veth pair,
each end
connected to 1 bd... not a real solution for me.

I thought I could write an 'xconnect-tx node' to be able to
transfer the
packets (this node would be like the output classifier ), but I
wanted first to know whether this is the only solution.

Many thanks !
Christophe

[1] https://github.com/christophefontaine/tap-as-a-service
[2]
https://wiki.openstack.org/wiki/Blueprint-networking-vpp-taas#Possi
ble
_implementations
This message and any attachments (the "message") are confidential,
intended solely for the addressees. If you are not the intended recipient,
please notify the sender immediately by e-mail and delete this message
from your system. In this case, you are not authorized to use, copy this
message and/or disclose the content to any other person. E-mails are
susceptible to alteration. Neither Qosmos nor any of its subsidiaries or
affiliates shall be liable for the message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous
avez reçu ce message par erreur, merci d’en informer immédiatement son
émetteur par courrier électronique et d’effacer ce message de votre
système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce
message et/ou en divulguer le contenu à un tiers. Tout message
électronique est susceptible d'altération. Qosmos et ses filiales déclinent
toute responsabilité au titre de ce message s'il a été altéré, déformé ou
falsifié.

This message and any attachments (the "message") are confidential, intended 
solely for the addressees. If you are not the intended recipient, please notify 
the sender immediately by e-mail and delete this message from your system. In 
this case, you are not authorized to use, copy this message and/or disclose the 
content to any other person. E-mails are susceptible to alteration. Neither 
Qosmos nor any of its subsidiaries or affiliates shall be liable for the 
message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont 
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous 
avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur 
par courrier électronique et d’effacer ce message de votre système. Dans cette 
hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en 
divulguer le contenu à un tiers. Tout message électronique est susceptible 
d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de 
ce message s'il a été altéré, déformé ou falsifié.


This message and any attachments (the "message") are confidential, intended 
solely for the addressees. If you are not the intended recipient, please notify 
the sender immediately by e-mail and delete this message from your system. In 
this case, you are not authorized to use, copy this message and/or disclose the 
content to any other person. E-mails are susceptible to alteration. Neither 
Qosmos nor any of its subsidiaries or affiliates shall be liable for the 
message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont 
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous 
avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur 
par courrier électronique et d’effacer ce message de votre système. Dans cette 
hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en 
divulguer le contenu à un tiers. Tout message électronique est susceptible 
d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de 
ce message s'il a été altéré, déformé ou falsifié.

This message and any attachments (the "message") are confidential, intended 
solely for the addressees. If you are not the intended recipient, please notify 
the sender immediately by e-mail and delete this message from your system. In 
this case, you are not authorized to use, copy this message and/or disclose the 
content to any other person. E-mails are susceptible to alteration. Neither 
Qosmos nor any of its subsidiaries or affiliates shall be liable for the 
message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont 
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous 
avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur 
par courrier électronique et d’effacer ce message de votre système. Dans cette 
hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en 
divulguer le contenu à un tiers. Tout message électronique est susceptible 
d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de 
ce message s'il a été altéré, déformé ou falsifié.
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Reply via email to