date:20200812

Re: [vpp-dev] Query on Feature arc for tapping all IP packets after reassembly

2020-08-12 Thread Satya Murthy

Thanks a lot Matt for the quick inputs.

We are interested in packets destined for our interfaces only. Hence, I will 
try with ip4-local.

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17215): https://lists.fd.io/g/vpp-dev/message/17215
Mute This Topic: https://lists.fd.io/mt/76144894/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif

2020-08-12 Thread techiek7

Can anyone please check and revert on this config ?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17214): https://lists.fd.io/g/vpp-dev/message/17214
Mute This Topic: https://lists.fd.io/mt/76099289/21656
Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query on Feature arc for tapping all IP packets after reassembly

2020-08-12 Thread Matthew Smith via lists.fd.io

Hi Satya,

A node on ip4-local will process packets which have a destination IPv4
address that is local to VPP. Usually these are addresses configured on a
VPP interface but they can also be addresses in a NAT pool or any other
address which has a local path in the FIB. If those are the only packets
you want your node to process, then ip4-local should work. Otherwise, if
you want to process packets which  VPP will forward elsewhere, you might
want to use the ip4-unicast arc and set runs_after to
"ip4-full-reassembly-feature".

-Matt

On Wed, Aug 12, 2020 at 6:16 AM Satya Murthy 
wrote:

> Hi,
>
> We have a query on one of the requirements we have.
>
> 1. We would like to tap all the ip4 packets into our custom graph node.
> 2. But, we want to tap the ip packets only after reassembly is completed,
> if fragments are received.
>
> I was looking at ip-local feature arc, if this works for our requirement
> or not. But, I am not 100% sure, if the reassembly restriction will be met
> by registering our feature in ip4-local feature arc as below.
>
> VNET_FEATURE_INIT (our_custom_feature, static) =
> {
>   .arc_name = "ip4-local",
>   .node_name = "our-custom-node",
>   .runs_before = VNET_FEATURES("ip4-local-end-of-arc"),
> };
>
> If this does not work, can you please let us know any pointers on how to
> achieve this.
>
> Thanks & Regards,
> Murthy 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17211): https://lists.fd.io/g/vpp-dev/message/17211
Mute This Topic: https://lists.fd.io/mt/76144894/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] ABF and ACL co-existence on an Interface

2020-08-12 Thread Venkat

Neale,

No worries. Enjoy your vacation 

If the fix for issue 1 works where ACL and ABF can co-exist on an
interface, we can configure ACL for all deny/drop scenarios and ABF only
for the permit and forwarding traffic. So like you said, we will
configure ABFs always with forwarding paths with a fix for the issue 1
works.

thanks
Venkat



On Wed, Aug 12, 2020 at 10:05 AM Neale Ranns (nranns) 
wrote:

> Hi Venkat,
>
> No fix from me soon, I'm on leave. In the meantime, don't add policies
> with no forwarding paths ;)
>
> /neale
>
> tpyed by my fat tumhbs
>
> --
> *From:* Venkat 
> *Sent:* Wednesday, August 12, 2020 5:41:42 PM
> *To:* Andrew  Yourtchenko 
> *Cc:* Neale Ranns (nranns) ; Balaji Venkatraman
> (balajiv) ; vpp-dev@lists.fd.io 
> *Subject:* Re: [vpp-dev] ABF and ACL co-existence on an Interface
>
> Thank you Andrew for providing the fix. We will try the patch and let you
> know how it holds.
> Regarding the second issue, it appears to be some defensive check missing
> for the forwarding paths.
> The test scenario was to delete an ABF policy with no forwarding paths.
> Create was successful.
>
> Will wait for Neale to comment on the backtrace provided and hopefully get
> a fix from him soon.
>
> thanks
> Venkat
>
> On Wed, Aug 12, 2020 at 1:47 AM Andrew  Yourtchenko 
> wrote:
>
> Hi Venkat,
>
> Cool, thanks a lot!
>
> So the first issue is acl-related,
> you can try out the https://gerrit.fd.io/r/c/vpp/+/28251
>
> ACL plugin uses its own heap to get better isolation
> from the rest of the world, but the lookup
> contexts are sitting in the global heap -
>  and accidentally it was being  created in the wrong heap,
> thus tripping up the assertion later on.  (This is why you
> saw the unintended “either-or” behavior).
>
> The second issue seems to me to be purely in ABF code,
> so Neale will need to take a look.
>
> --a
>
> On 12 Aug 2020, at 02:39, Venkat  wrote:
>
> 
> Andrew/Neale,
>
> We spent some more time today trying to root cause the issues. The
> following are the VPP backtraces for the respective issues. We tried this
> on VPP version 20.05
> Hope this gives some clues towards fixing the issue.
>
> Issue 1 Test Scenario:  ABF and ACL attached to the same interface
>
> it is getting stuck at the spin_acquire_lock()
>
>
>
>  Thread 1 (Thread 0x77fe0c40 (LWP 28339)):
>
>  #0  0x743cff37 in sched_yield () at
> ../sysdeps/unix/syscall-template.S:78
>
>  #1  0x751beb87 in spin_acquire_lock (sl=)
>
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:468
>
>  #2  mspace_malloc (msp=0x7fffb42bc010, bytes=92) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4371
>
>  #3  0x751beaa9 in mspace_get_aligned (msp=0x7fffb42bc010,
> n_user_data_bytes=92, align=16,
>
>  align_offset=) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4254
>
>  #4  0x7521cd57 in clib_mem_alloc_aligned_at_offset (size=72,
> align=8, align_offset=8, os_out_of_memory_on_failure=1)
>
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:142
>
>  #5  vec_resize_allocate_memory (v=, length_increment=64,
> data_bytes=72, header_bytes=,
>
>  data_align=8, numa_id=255) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:67
>
>  #6  0x751fb670 in _vec_resize_inline (v=0x0,
> length_increment=, data_bytes=,
>
>  header_bytes=, data_align=,
> numa_id=)
>
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170
>
>  #7  serialize_vector_write (m=, s=0x7fffb5809980)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:903
>
>  #8  0x751fb2b7 in serialize_write_not_inline (m=0x7fffb5809920,
> s=0x7fffb5809980, n_bytes_to_write=4,
>
>  flags=) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:729
>
>  #9  0x77bc77dc in serialize_stream_read_write
> (header=0x7fffb5809920, s=, n_bytes=4, flags=2)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:140
>
>  #10 serialize_get (m=0x7fffb5809920, n_bytes=4) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:180
>
>  #11 serialize_integer (m=0x7fffb5809920, n_bytes=4, x=)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:187
>
>  #12 vl_api_serialize_message_table (am=0x77dd3c28 ,
> vector=)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:212
>
>  #13 0x77bc7cb6 in vl_msg_api_trace_save (am=0x7fffb42bc010,
> which=, fp=0x55986b80)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:261
>
>  #14 0x77bc989d in vl_msg_api_post_mortem_dump ()
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:944
>
>  #15 0xc756 in os_panic () at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vpp/vnet/main.c:364
>
>  #16 0x751c0afb in mspace_free (msp=0x7fffb42bc010,
>

Re: [vpp-dev] ABF and ACL co-existence on an Interface

2020-08-12 Thread Balaji Venkatraman via lists.fd.io

Make sense!

Thank much, Neale.

--
Regards,
Balaji.


From: "Neale Ranns (nranns)" 
Date: Wednesday, August 12, 2020 at 10:20 AM
To: "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" , Venkat 
, Andrew  Yourtchenko 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface


Hi Balaji,
Access control happens before forwarding, so the ABF plugin specifies a 
runs-after dependency on the ACL plugin
So if the same tuple is specified in the access lists used by the two features, 
then that flow is first subject to access control, then, if it is permitted, to 
forwarding.
/neale
tpyed by my fat tumhbs


From: Balaji Venkatraman (balajiv) 
Sent: Wednesday, August 12, 2020 5:08:51 PM
To: Neale Ranns (nranns) 
Cc: vpp-dev@lists.fd.io ; Venkat 
; Andrew  Yourtchenko 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface


Hi Neale,



Just wondering what the behavior ought to be if we had a ACL policy to drop on 
an IP address and ABF has one to fwd it.. Which one prevails?



Thanks!



--

Regards,

Balaji.





--

Regards,

Balaji.





From: "Neale Ranns (nranns)" 
Date: Tuesday, August 11, 2020 at 8:30 AM
To: Venkat , Andrew  Yourtchenko 
, "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface





IMO it's reasonable to use ACL and ABF on the same interface as they provide 
independent functions, especially when they are matching against different 
criteria.

Re the debug CLI, it's often not robust to garbage input. If the API has the 
same problem though, I'll fix it.

Neale

tpyed by my fat tumhbs





From: vpp-dev@lists.fd.io  on behalf of Balaji Venkatraman 
via lists.fd.io 
Sent: Tuesday, August 11, 2020 4:08:56 PM
To: Venkat ; Andrew  Yourtchenko 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface



Hi Venkat,

Ideally, we should not let ABF be configured if the interface is already tied 
to an ACL. Conversely, an ACL should be honored when the interface is tied to 
an ABF. Right?

You might want to confirm how we handle the behavior from experts here.

BTW, the second scenario you seeing the crash..

Issue 2: Delete ABF Policy that doesn’t have forwarding Path



That is an interesting scenario. Shouldn’t ABF mandatorily have an underlying 
ACL with a forwarding path?





Thanks!

—

Regards,

Balaji.



Get Outlook for iOS



From: vpp-dev@lists.fd.io  on behalf of Venkat 

Sent: Monday, August 10, 2020 11:52:46 PM
To: Andrew  Yourtchenko 
Cc: Balaji Venkatraman (balajiv) ; vpp-dev@lists.fd.io 

Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface



Hi Andrew,



Here are a couple of test scenarios where I observed vpp crash while 
experimenting with ABF configuration.

I will find time to translate them to make test cases soon.

Meanwhile here are the steps to reproduce the issues.



Issues 1: ABF and ACL attached to the same interface



• In vpp VAT shell and configure bunch of ACL rules in a group



vat# acl_add_replace  ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24, ipv4 permit+reflect src 
20.20.20.0/24

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 0



• Attach ACL Group create above to lan interface



vat# acl_interface_set_acl_list sw_if_index 1 input 0



• Following will be the state in vpp



DBGvpp# show version

vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
21:10:49 UTC 2020

DBGvpp#



DBGvpp# show hardware-interfaces brief

  NameIdx   Link  Hardware

lan1 up   lan

  Link speed: 10 Gbps

local0 0down  local0

  Link speed: unknown

loop0  3 up   loop0

  Link speed: unknown

loop1  5 up   loop1

  Link speed: unknown

tap0   4 up   tap0

  Link speed: unknown

wan2 up   wan

  Link speed: 1 Gbps



DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0



DBGvpp# show acl-plugin interface

sw_if_index 0:

sw_if_index 1:

  input acl(s): 0

DBGvpp#



• Create another ACL for ABF

Re: [vpp-dev] ABF and ACL co-existence on an Interface

2020-08-12 Thread Neale Ranns via lists.fd.io


Hi Balaji,

Access control happens before forwarding, so the ABF plugin specifies a 
runs-after dependency on the ACL plugin

So if the same tuple is specified in the access lists used by the two features, 
then that flow is first subject to access control, then, if it is permitted, to 
forwarding.

/neale

tpyed by my fat tumhbs


From: Balaji Venkatraman (balajiv) 
Sent: Wednesday, August 12, 2020 5:08:51 PM
To: Neale Ranns (nranns) 
Cc: vpp-dev@lists.fd.io ; Venkat 
; Andrew  Yourtchenko 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface


Hi Neale,



Just wondering what the behavior ought to be if we had a ACL policy to drop on 
an IP address and ABF has one to fwd it.. Which one prevails?



Thanks!



--

Regards,

Balaji.





--

Regards,

Balaji.





From: "Neale Ranns (nranns)" 
Date: Tuesday, August 11, 2020 at 8:30 AM
To: Venkat , Andrew  Yourtchenko 
, "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface





IMO it's reasonable to use ACL and ABF on the same interface as they provide 
independent functions, especially when they are matching against different 
criteria.

Re the debug CLI, it's often not robust to garbage input. If the API has the 
same problem though, I'll fix it.

Neale

tpyed by my fat tumhbs





From: vpp-dev@lists.fd.io  on behalf of Balaji Venkatraman 
via lists.fd.io 
Sent: Tuesday, August 11, 2020 4:08:56 PM
To: Venkat ; Andrew  Yourtchenko 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface



Hi Venkat,

Ideally, we should not let ABF be configured if the interface is already tied 
to an ACL. Conversely, an ACL should be honored when the interface is tied to 
an ABF. Right?

You might want to confirm how we handle the behavior from experts here.

BTW, the second scenario you seeing the crash..

Issue 2: Delete ABF Policy that doesn’t have forwarding Path



That is an interesting scenario. Shouldn’t ABF mandatorily have an underlying 
ACL with a forwarding path?





Thanks!

—

Regards,

Balaji.



Get Outlook for iOS



From: vpp-dev@lists.fd.io  on behalf of Venkat 

Sent: Monday, August 10, 2020 11:52:46 PM
To: Andrew  Yourtchenko 
Cc: Balaji Venkatraman (balajiv) ; vpp-dev@lists.fd.io 

Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface



Hi Andrew,



Here are a couple of test scenarios where I observed vpp crash while 
experimenting with ABF configuration.

I will find time to translate them to make test cases soon.

Meanwhile here are the steps to reproduce the issues.



Issues 1: ABF and ACL attached to the same interface



· In vpp VAT shell and configure bunch of ACL rules in a group



vat# acl_add_replace  ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24, ipv4 permit+reflect src 
20.20.20.0/24

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 0



· Attach ACL Group create above to lan interface



vat# acl_interface_set_acl_list sw_if_index 1 input 0



· Following will be the state in vpp



DBGvpp# show version

vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
21:10:49 UTC 2020

DBGvpp#



DBGvpp# show hardware-interfaces brief

  NameIdx   Link  Hardware

lan1 up   lan

  Link speed: 10 Gbps

local0 0down  local0

  Link speed: unknown

loop0  3 up   loop0

  Link speed: unknown

loop1  5 up   loop1

  Link speed: unknown

tap0   4 up   tap0

  Link speed: unknown

wan2 up   wan

  Link speed: 1 Gbps



DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0



DBGvpp# show acl-plugin interface

sw_if_index 0:

sw_if_index 1:

  input acl(s): 0

DBGvpp#



· Create another ACL for ABF configuration



vat# acl_add_replace  ipv4 permit src 11.11.11.0/24 proto 
17

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 1



DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst

Re: [vpp-dev] ABF and ACL co-existence on an Interface

2020-08-12 Thread Venkat

Thank you Andrew for providing the fix. We will try the patch and let you
know how it holds.
Regarding the second issue, it appears to be some defensive check missing
for the forwarding paths.
The test scenario was to delete an ABF policy with no forwarding paths.
Create was successful.

Will wait for Neale to comment on the backtrace provided and hopefully get
a fix from him soon.

thanks
Venkat

On Wed, Aug 12, 2020 at 1:47 AM Andrew  Yourtchenko 
wrote:

> Hi Venkat,
>
> Cool, thanks a lot!
>
> So the first issue is acl-related,
> you can try out the https://gerrit.fd.io/r/c/vpp/+/28251
>
> ACL plugin uses its own heap to get better isolation
> from the rest of the world, but the lookup
> contexts are sitting in the global heap -
>  and accidentally it was being  created in the wrong heap,
> thus tripping up the assertion later on.  (This is why you
> saw the unintended “either-or” behavior).
>
> The second issue seems to me to be purely in ABF code,
> so Neale will need to take a look.
>
> --a
>
> On 12 Aug 2020, at 02:39, Venkat  wrote:
>
> 
> Andrew/Neale,
>
> We spent some more time today trying to root cause the issues. The
> following are the VPP backtraces for the respective issues. We tried this
> on VPP version 20.05
> Hope this gives some clues towards fixing the issue.
>
> Issue 1 Test Scenario:  ABF and ACL attached to the same interface
>
> it is getting stuck at the spin_acquire_lock()
>
>
>
>  Thread 1 (Thread 0x77fe0c40 (LWP 28339)):
>
>  #0  0x743cff37 in sched_yield () at
> ../sysdeps/unix/syscall-template.S:78
>
>  #1  0x751beb87 in spin_acquire_lock (sl=)
>
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:468
>
>  #2  mspace_malloc (msp=0x7fffb42bc010, bytes=92) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4371
>
>  #3  0x751beaa9 in mspace_get_aligned (msp=0x7fffb42bc010,
> n_user_data_bytes=92, align=16,
>
>  align_offset=) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4254
>
>  #4  0x7521cd57 in clib_mem_alloc_aligned_at_offset (size=72,
> align=8, align_offset=8, os_out_of_memory_on_failure=1)
>
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:142
>
>  #5  vec_resize_allocate_memory (v=, length_increment=64,
> data_bytes=72, header_bytes=,
>
>  data_align=8, numa_id=255) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:67
>
>  #6  0x751fb670 in _vec_resize_inline (v=0x0,
> length_increment=, data_bytes=,
>
>  header_bytes=, data_align=,
> numa_id=)
>
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170
>
>  #7  serialize_vector_write (m=, s=0x7fffb5809980)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:903
>
>  #8  0x751fb2b7 in serialize_write_not_inline (m=0x7fffb5809920,
> s=0x7fffb5809980, n_bytes_to_write=4,
>
>  flags=) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:729
>
>  #9  0x77bc77dc in serialize_stream_read_write
> (header=0x7fffb5809920, s=, n_bytes=4, flags=2)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:140
>
>  #10 serialize_get (m=0x7fffb5809920, n_bytes=4) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:180
>
>  #11 serialize_integer (m=0x7fffb5809920, n_bytes=4, x=)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:187
>
>  #12 vl_api_serialize_message_table (am=0x77dd3c28 ,
> vector=)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:212
>
>  #13 0x77bc7cb6 in vl_msg_api_trace_save (am=0x7fffb42bc010,
> which=, fp=0x55986b80)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:261
>
>  #14 0x77bc989d in vl_msg_api_post_mortem_dump ()
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:944
>
>  #15 0xc756 in os_panic () at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vpp/vnet/main.c:364
>
>  #16 0x751c0afb in mspace_free (msp=0x7fffb42bc010,
> mem=)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4548
>
>  #17 0x7521cf0b in clib_mem_free (p=) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:224
>
>  #18 vec_resize_allocate_memory (v=,
> length_increment=, data_bytes=,
>
>  header_bytes=56, data_align=, numa_id=)
>
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:119
>
>  #19 0x7fffb3e1f4e0 in _vec_resize_inline (v=,
> length_increment=1, data_bytes=24, header_bytes=48,
>
>  data_align=8, numa_id=255) at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170
>
>  #20 acl_plugin_get_lookup_context_index (acl_user_id=1, val1=1, val2=0)
>
>  at
> /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/acl/lookup_context.c:112
>
>  #21 0x7fffb40b4ab5 in abf_itf_attach (fproto=FIB_PROTOCOL_IP4,
> policy_id=, priority=0,
>
>

Re: [vpp-dev] ABF and ACL co-existence on an Interface

2020-08-12 Thread Balaji Venkatraman via lists.fd.io

Hi Neale,

Just wondering what the behavior ought to be if we had a ACL policy to drop on 
an IP address and ABF has one to fwd it.. Which one prevails?

Thanks!

--
Regards,
Balaji.


--
Regards,
Balaji.


From: "Neale Ranns (nranns)" 
Date: Tuesday, August 11, 2020 at 8:30 AM
To: Venkat , Andrew  Yourtchenko 
, "Balaji Venkatraman (balajiv)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface


IMO it's reasonable to use ACL and ABF on the same interface as they provide 
independent functions, especially when they are matching against different 
criteria.
Re the debug CLI, it's often not robust to garbage input. If the API has the 
same problem though, I'll fix it.
Neale
tpyed by my fat tumhbs


From: vpp-dev@lists.fd.io  on behalf of Balaji Venkatraman 
via lists.fd.io 
Sent: Tuesday, August 11, 2020 4:08:56 PM
To: Venkat ; Andrew  Yourtchenko 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface

Hi Venkat,
Ideally, we should not let ABF be configured if the interface is already tied 
to an ACL. Conversely, an ACL should be honored when the interface is tied to 
an ABF. Right?
You might want to confirm how we handle the behavior from experts here.
BTW, the second scenario you seeing the crash..
Issue 2: Delete ABF Policy that doesn’t have forwarding Path


That is an interesting scenario. Shouldn’t ABF mandatorily have an underlying 
ACL with a forwarding path?


Thanks!
—
Regards,
Balaji.

Get Outlook for iOS

From: vpp-dev@lists.fd.io  on behalf of Venkat 

Sent: Monday, August 10, 2020 11:52:46 PM
To: Andrew  Yourtchenko 
Cc: Balaji Venkatraman (balajiv) ; vpp-dev@lists.fd.io 

Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface

Hi Andrew,

Here are a couple of test scenarios where I observed vpp crash while 
experimenting with ABF configuration.
I will find time to translate them to make test cases soon.
Meanwhile here are the steps to reproduce the issues.


Issues 1: ABF and ACL attached to the same interface


· In vpp VAT shell and configure bunch of ACL rules in a group


vat# acl_add_replace  ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 sport 1000 dport 1000, ipv4 permit+reflect 
src 10.10.10.0/24, ipv4 permit+reflect src 
20.20.20.0/24

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 0


· Attach ACL Group create above to lan interface


vat# acl_interface_set_acl_list sw_if_index 1 input 0


· Following will be the state in vpp


DBGvpp# show version

vpp v19.08.1-282~ga6a98b546 built by root on 525c154d7fe6 at Tue Aug  4 
21:10:49 UTC 2020

DBGvpp#


DBGvpp# show hardware-interfaces brief

  NameIdx   Link  Hardware

lan1 up   lan

  Link speed: 10 Gbps

local0 0down  local0

  Link speed: unknown

loop0  3 up   loop0

  Link speed: unknown

loop1  5 up   loop1

  Link speed: unknown

tap0   4 up   tap0

  Link speed: unknown

wan2 up   wan

  Link speed: 1 Gbps


DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0


DBGvpp# show acl-plugin interface

sw_if_index 0:

sw_if_index 1:

  input acl(s): 0

DBGvpp#


· Create another ACL for ABF configuration


vat# acl_add_replace  ipv4 permit src 11.11.11.0/24 proto 
17

vl_api_acl_add_replace_reply_t_handler:109: ACL index: 1


DBGvpp# show acl-plugin acl

acl-index 0 count 3 tag {}

  0: ipv4 permit src 30.30.30.1/32 dst 
40.40.40.1/32 proto 0 sport 1000 dport 1000

  1: ipv4 permit+reflect src 10.10.10.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  2: ipv4 permit+reflect src 20.20.20.0/24 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0

acl-index 1 count 1 tag {}

  0: ipv4 permit src 11.11.11.0/24 dst 
0.0.0.0/0 proto 17 sport 0-65535 dport 0-65535

DBGvpp#


· Configure ABF Policy referring to the above created

Re: [vpp-dev] address sanitizer and unit tests not working

2020-08-12 Thread Christian Hopps



> On Aug 12, 2020, at 10:12 AM, Benoit Ganne (bganne)  wrote:
> 
> Hi Christian,
> 
> Thanks for the head's up.
> 
>> I think maybe the right thing to do here is create a custom cmake build
>> rule to stage the entire python package in build-root/build*
> 
> Alternatively, do you know if we can add an arbitrary file to be packaged by 
> setup.py? If we could just tell ssetup.py 'take also this absolute filename' 
> that would allow us to generate the vpp_ffi.py in build-root and left the 
> rest unchanged...

Not exaclty. I think if you made the generated file part of a sub-pkg maybe you 
could use this?

https://docs.python.org/3/distutils/setupscript.html#listing-whole-packages 


Alternatively, is there a way to figure out if ASAN is required by the ffi 
dlopen at runtime? Then we wouldn't need to generate different source files.

Thanks,
Chris.

> 
> Best
> ben
> 



signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17203): https://lists.fd.io/g/vpp-dev/message/17203
Mute This Topic: https://lists.fd.io/mt/75917538/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] address sanitizer and unit tests not working

2020-08-12 Thread Benoit Ganne (bganne) via lists.fd.io

Hi Christian,

Thanks for the head's up.

> I think maybe the right thing to do here is create a custom cmake build
> rule to stage the entire python package in build-root/build*

Alternatively, do you know if we can add an arbitrary file to be packaged by 
setup.py? If we could just tell ssetup.py 'take also this absolute filename' 
that would allow us to generate the vpp_ffi.py in build-root and left the rest 
unchanged...

Best
ben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17202): https://lists.fd.io/g/vpp-dev/message/17202
Mute This Topic: https://lists.fd.io/mt/75917538/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

2020-08-12 Thread Dave Barach via lists.fd.io

Minus the typo this time:

vpp# ip table 1
vpp# set int ip table  1

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
lists.fd.io
Sent: Wednesday, August 12, 2020 9:08 AM
To: techi...@gmail.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Unable to create fib table and add interfaces in vpp 
20.09

“... create fib table and add interface to it.”

You need to actually create the table:

vpp# ip table 1
vpp# set int  ip table 1

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of 
techi...@gmail.com
Sent: Wednesday, August 12, 2020 8:47 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

Hello Team,

I have two physical NIC attached to vpp-dpdk. vpp throws following error when I 
try to create fib table and add interface to it.

set interface ip table GigabitEthernet4/0/0 1 ---> set interface ip table: 
no such table 1

"set interface ip table" command should create table for given table id 
according to documentation.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17200): https://lists.fd.io/g/vpp-dev/message/17200
Mute This Topic: https://lists.fd.io/mt/76146302/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

2020-08-12 Thread techiek7

Got it. Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17201): https://lists.fd.io/g/vpp-dev/message/17201
Mute This Topic: https://lists.fd.io/mt/76146302/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

2020-08-12 Thread Dave Barach via lists.fd.io

“... create fib table and add interface to it.”

You need to actually create the table:

vpp# ip table 1
vpp# set int  ip table 1

From: vpp-dev@lists.fd.io  On Behalf Of techi...@gmail.com
Sent: Wednesday, August 12, 2020 8:47 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

Hello Team,

I have two physical NIC attached to vpp-dpdk. vpp throws following error when I 
try to create fib table and add interface to it.

set interface ip table GigabitEthernet4/0/0 1 ---> set interface ip table: 
no such table 1

"set interface ip table" command should create table for given table id 
according to documentation.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17199): https://lists.fd.io/g/vpp-dev/message/17199
Mute This Topic: https://lists.fd.io/mt/76146302/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

2020-08-12 Thread techiek7

Hello Team,

I have two physical NIC attached to vpp-dpdk. vpp throws following error when I 
try to create fib table and add interface to it.

set interface ip table GigabitEthernet4/0/0 1 ---> set interface ip table: 
no such table 1

"set interface ip table" command should create table for given table id 
according to documentation.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17198): https://lists.fd.io/g/vpp-dev/message/17198
Mute This Topic: https://lists.fd.io/mt/76145976/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VAPI getting hanged on VPP restart

2020-08-12 Thread Chinmaya Aggarwal

Hi,
I have an application that uses vapi to connect to vpp. If I restart VPP, my 
application gets stuck at the first vapi call. I then have to restart my 
application to bring back it to normal state. I think this is due to a broken 
connection.
Is there a way to reconnect to vpp without restarting my application?

Similar kind of issue has been reported by someone else as well :-
https://lists.fd.io/g/vpp-dev/message/16909?p=,,,20,0,0,0::Created,,vapi,20,2,0,75370134

It would be really great if someone could share insights into this issue?

Thanks and Regards,
Chinmaya Agarwal
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17197): https://lists.fd.io/g/vpp-dev/message/17197
Mute This Topic: https://lists.fd.io/mt/76145831/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] address sanitizer and unit tests not working

2020-08-12 Thread Christian Hopps

FWIW I looked at this briefly but started rat-holing trying to better integrate 
the python packaging (which I am somewhat familiar with) with cmake (which I 
know almost nothing about).

I think maybe the right thing to do here is create a custom cmake build rule to 
stage the entire python package in build-root/build* doing the pattern 
substitution on vpp_ffi.py.in as well as setup.py (to set a package_dir to 
point to the new staging location). Then the install rule would run "python 
setup.py install" inside that staging build dir with the arguments to install 
in the build-root/install* location (this latter rule is already there). This 
gets away from modifying files inside the source directory, as not modifying 
source directory files seems the expected behavior when using cmake.

I'm not sure of the cmake magic to set dependencies correctly so that the 
custom build rule to copy the files gets invoked whenever a source python file 
changes, or ASAN is disabled or enabled, and how to carry those dependencies 
forward to the install rule.

Thanks,
Chris.

> On Aug 7, 2020, at 12:01 PM, Benoit Ganne (bganne) via lists.fd.io 
>  wrote:
> 
>> If I clear the runner (gitlab) cache it causes a full rebuild, and then I
>> don't see the problem.
>> Shouldn't the generated file be going under build-root? I ask b/c it's
>> showing up in git status now. Maybe this also affects the cmake
>> dependency?
> 
> Hmm great point, I'll see how to fix that.
> 
> Best
> ben
> 

signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17196): https://lists.fd.io/g/vpp-dev/message/17196
Mute This Topic: https://lists.fd.io/mt/75917538/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Query on Feature arc for tapping all IP packets after reassembly

2020-08-12 Thread Satya Murthy

Hi,

We have a query on one of the requirements we have.

1. We would like to tap all the ip4 packets into our custom graph node.
2. But, we want to tap the ip packets only after reassembly is completed, if 
fragments are received.

I was looking at ip-local feature arc, if this works for our requirement or 
not. But, I am not 100% sure, if the reassembly restriction will be met by 
registering our feature in ip4-local feature arc as below.

VNET_FEATURE_INIT (our_custom_feature, static) =
{
.arc_name = "ip4-local",
.node_name = "our-custom-node",
.runs_before = VNET_FEATURES("ip4-local-end-of-arc"),
};

If this does not work, can you please let us know any pointers on how to 
achieve this.

Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17195): https://lists.fd.io/g/vpp-dev/message/17195
Mute This Topic: https://lists.fd.io/mt/76144894/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif

2020-08-12 Thread techiek7

Hello Ben,

I tried below configuration, Packet rx on physical nic are visible in 
application through memif, and they are written-back successfully to memif. but 
they are not reaching intended destination.

vppctl create interface memif id 0 master
vppctl set int state memif0/0 up
vppctl set int ip address memif0/0 192.168.1.1/24
vppctl set interface state GigabitEthernet3/0/0 up
vppctl set interface state GigabitEthernet4/0/0 up
vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24
vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24

vppctl abf policy add id 1 acl 0 via GigabitEthernet3/0/0
vppctl abf attach ip4 policy 1 priority 0 memif0/0
vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#17194): https://lists.fd.io/g/vpp-dev/message/17194
Mute This Topic: https://lists.fd.io/mt/76099289/21656
Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] ABF and ACL co-existence on an Interface

2020-08-12 Thread Andrew Yourtchenko

Hi Venkat,

Cool, thanks a lot! 

So the first issue is acl-related,
you can try out the https://gerrit.fd.io/r/c/vpp/+/28251

ACL plugin uses its own heap to get better isolation 
from the rest of the world, but the lookup 
contexts are sitting in the global heap -
 and accidentally it was being  created in the wrong heap,
thus tripping up the assertion later on.  (This is why you 
saw the unintended “either-or” behavior).

The second issue seems to me to be purely in ABF code, 
so Neale will need to take a look.

--a

>> On 12 Aug 2020, at 02:39, Venkat  wrote:
> 
> Andrew/Neale, 
> 
> We spent some more time today trying to root cause the issues. The following 
> are the VPP backtraces for the respective issues. We tried this on VPP 
> version 20.05
> Hope this gives some clues towards fixing the issue. 
> 
> Issue 1 Test Scenario:  ABF and ACL attached to the same interface
> 
> it is getting stuck at the spin_acquire_lock()
>
>  Thread 1 (Thread 0x77fe0c40 (LWP 28339)):
>  #0  0x743cff37 in sched_yield () at 
> ../sysdeps/unix/syscall-template.S:78
>  #1  0x751beb87 in spin_acquire_lock (sl=)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:468
>  #2  mspace_malloc (msp=0x7fffb42bc010, bytes=92) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4371
>  #3  0x751beaa9 in mspace_get_aligned (msp=0x7fffb42bc010, 
> n_user_data_bytes=92, align=16, 
>  align_offset=) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4254
>  #4  0x7521cd57 in clib_mem_alloc_aligned_at_offset (size=72, 
> align=8, align_offset=8, os_out_of_memory_on_failure=1)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:142
>  #5  vec_resize_allocate_memory (v=, length_increment=64, 
> data_bytes=72, header_bytes=, 
>  data_align=8, numa_id=255) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:67
>  #6  0x751fb670 in _vec_resize_inline (v=0x0, 
> length_increment=, data_bytes=, 
>  header_bytes=, data_align=, 
> numa_id=)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170
>  #7  serialize_vector_write (m=, s=0x7fffb5809980)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:903
>  #8  0x751fb2b7 in serialize_write_not_inline (m=0x7fffb5809920, 
> s=0x7fffb5809980, n_bytes_to_write=4, 
>  flags=) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.c:729
>  #9  0x77bc77dc in serialize_stream_read_write 
> (header=0x7fffb5809920, s=, n_bytes=4, flags=2)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:140
>  #10 serialize_get (m=0x7fffb5809920, n_bytes=4) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:180
>  #11 serialize_integer (m=0x7fffb5809920, n_bytes=4, x=)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/serialize.h:187
>  #12 vl_api_serialize_message_table (am=0x77dd3c28 , 
> vector=)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:212
>  #13 0x77bc7cb6 in vl_msg_api_trace_save (am=0x7fffb42bc010, 
> which=, fp=0x55986b80)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:261
>  #14 0x77bc989d in vl_msg_api_post_mortem_dump ()
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vlibapi/api_shared.c:944
>  #15 0xc756 in os_panic () at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vpp/vnet/main.c:364
>  #16 0x751c0afb in mspace_free (msp=0x7fffb42bc010, mem= out>)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/dlmalloc.c:4548
>  #17 0x7521cf0b in clib_mem_free (p=) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/mem.h:224
>  #18 vec_resize_allocate_memory (v=, 
> length_increment=, data_bytes=, 
>  header_bytes=56, data_align=, numa_id=)
>  at /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.c:119
>  #19 0x7fffb3e1f4e0 in _vec_resize_inline (v=, 
> length_increment=1, data_bytes=24, header_bytes=48, 
>  data_align=8, numa_id=255) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vppinfra/vec.h:170
>  #20 acl_plugin_get_lookup_context_index (acl_user_id=1, val1=1, val2=0)
>  at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/acl/lookup_context.c:112
>  #21 0x7fffb40b4ab5 in abf_itf_attach (fproto=FIB_PROTOCOL_IP4, 
> policy_id=, priority=0, 
>  sw_if_index=) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/abf/abf_itf_attach.c:227
>  #22 0x7fffb40b7327 in abf_itf_attach_cmd (vm=, 
> input=, cmd=)
>  at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/plugins/abf/abf_itf_attach.c:397
>  #23 0x75d6f752 in vlib_cli_dispatch_sub_commands (vm=0x76012500 
> , cm=, 
>  input=0x7fffb5809f60, parent_command_index=) at 
> /w/workspace/vpp-merge-2005-ubuntu1804/src/vlib/cli.c:568
>  #24 0x75d6f669 in vlib_cli_dispatch_sub_commands (vm=0x76012500 
> ,

Re: [vpp-dev] Query on Feature arc for tapping all IP packets after reassembly

Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif

Re: [vpp-dev] Query on Feature arc for tapping all IP packets after reassembly

Re: [vpp-dev] ABF and ACL co-existence on an Interface

Re: [vpp-dev] ABF and ACL co-existence on an Interface

Re: [vpp-dev] ABF and ACL co-existence on an Interface

Re: [vpp-dev] ABF and ACL co-existence on an Interface

Re: [vpp-dev] ABF and ACL co-existence on an Interface

Re: [vpp-dev] address sanitizer and unit tests not working

Re: [vpp-dev] address sanitizer and unit tests not working

Re: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

Re: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

Re: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

[vpp-dev] Unable to create fib table and add interfaces in vpp 20.09

[vpp-dev] VAPI getting hanged on VPP restart

Re: [vpp-dev] address sanitizer and unit tests not working

[vpp-dev] Query on Feature arc for tapping all IP packets after reassembly

Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif

Re: [vpp-dev] ABF and ACL co-existence on an Interface

19 matches

Site Navigation

Mail list logo

Footer information