date:20210518

[vpp-dev] Maximum support in vpp

2021-05-18 Thread Aiyasamy2 Dhanasekaran

Hi,
We are in the development phase for 5G user plane as vpp.
So I want to know about the following questions.

*Max buffers on per UPF-U
*Max tunnels in vpp
*Max QOS flows in vpp
*Max buffers per tunnel in vpp
*Max filters per tunnel  in vpp
*Max filters per UPF-U
Please kindly reply if you know the maximum values for the above

Thanks and regards,
Aiyasamy Dhanasekaran
=
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19405): https://lists.fd.io/g/vpp-dev/message/19405
Mute This Topic: https://lists.fd.io/mt/82929774/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] plugin to filter packets

2021-05-18 Thread Alex Syrnikov


Hello, VPP developers.

I can't understand how to write plugin to filter some packets and 
passing others.

I need to hook on some feature graph, check every packet and remove matched.

I bound required IP for interface, hooked arc "ip4-local" (it can also
be "ip4-unicast") with my node "checker" and do not understand how to
write node function. My node function work if I enable plugin for interface.

If I use node with next nodes as created by extras/emacs/make-plugin.sh
VLIB_REGISTER_NODE (checker_node) =
{
  // ...
  .n_next_nodes = CHECKER_N_NEXT,
  .next_nodes = {
    [CHECKER_NEXT_DROP] = "error-drop",
  },
};

I do not understand how to pass buffer to further nodes on arc in node 
function

- so all packets dropped because next[0] = 0;

Also as I understand feature arc can have many features enabled and all 
packets
will be processed by all nodes on arc, so I do not know which node on 
"ip4-local"

or "ip4-unicast" arc will be after my node to pass buffer there. So I do not
understand what to write in .next_nodes except "error-drop" to pass 
unfiltered

packets to further processing.

If I use .n_next_nodes = 0, all packets will pass to next node on 
feature arc,

but how to drop matched buffers?

The best solution I found is to use vlib_buffer_free() or code like this

  vlib_node_t* drop_node = vlib_get_node_by_name (vm, (u8 *)"error-drop");
  vlib_frame_t* f = vlib_get_frame_to_node (vm, drop_node->index );
  f->n_vectors = 1;
  u32* to_next = vlib_frame_vector_args( f );
  to_next[0] = buffer_index;

  vlib_put_frame_to_node( vm, drop_node->index, f );

and remove matched buffer indexes from vlib_buffer_enqueue_to_next().

(I know vlib_get_node_by_name() can be moved out of loop - this is not 
important.)
But this solution will break batch processing architecture of vpp and I 
think

there is better way (this looks like hack).

As I understand I just need to assign some index to next[0] which is 
nexts for


vlib_buffer_enqueue_to_next (vm, node, from, nexts, frame->n_vectors)

but I do not understand how to get it.

Please help to write node function which will drop matched packets and 
pass to

next node on arc unmatched. What do I need to write in

.next_nodes of VLIB_REGISTER_NODE

and how to drop matched buffers and pass others to next nodes on feature 
arc in node function.


Alex



OpenPGP_0x8C4121F027D4C2A9.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19404): https://lists.fd.io/g/vpp-dev/message/19404
Mute This Topic: https://lists.fd.io/mt/82921204/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Plugin and getting packets from Bonded interface. #vpp-memif #vpp-hoststack #vnet

2021-05-18 Thread RaviKiran Veldanda

Hi Team,
We developed a plugin in VPP to read data from a physical interface and forward 
to our application,

Packet 2

*03:03:45:254785: dpdk-input*
*HundredGigabitEthernet12/0/0 rx queue 0*
buffer 0x1f3a68: current data 0, length 114, buffer-pool 0, ref-count 1, 
totlen-nifb 132, trace handle 0x101
ext-hdr-valid
PKT MBUF: port 0, nb_segs 1, pkt_len 114
buf_len 9344, data_len 114, ol_flags 0x182, data_off 128, phys_addr 0xf28e9a80
packet_type 0x2e1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x42828e0 fdir.hi 0x0 fdir.lo 0x42828e0
Packet Offload Flags
PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV6_EXT_UNKNOWN (0x00e0) IPv6 packet with or without extension 
headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
IP6: b8:83:03:81:55:e0 -> 33:33:00:00:99:01 802.1q vlan 501
UDP: 2001:5b0::501:b883:31f:181:55e0 -> ff38:23:2001:5b0:2000::9901
tos 0x00, flow label 0x88b96, hop limit 254, payload length 56
UDP: 58362 -> 9901
length 56, checksum 0x6a9b
*03:03:45:254786: ipgw_ent*
*IPGW_ENT: sw_if_index 2, next index 0*
new src b8:83:03:81:55:e0 -> new dst 33:33:00:00:99:01
03:03:45:254787: ethernet-input
IP6: b8:83:03:81:55:e0 -> 33:33:00:00:99:01 802.1q vlan 501
03:03:45:254787: ip6-input
UDP: 2001:5b0::501:b883:31f:181:55e0 -> ff38:23:2001:5b0:2000::9901
tos 0x00, flow label 0x88b96, hop limit 254, payload length 56
UDP: 58362 -> 9901
length 56, checksum 0x6a9b
03:03:45:254787: ip6-mfib-forward-lookup
fib 0 entry 3
03:03:45:254787: ip6-mfib-forward-rpf
entry 3 itf -1 flags
03:03:45:254788: ip6-drop
UDP: 2001:5b0::501:b883:31f:181:55e0 -> ff38:23:2001:5b0:2000::9901
tos 0x00, flow label 0x88b96, hop limit 254, payload length 56
UDP: 58362 -> 9901
length 56, checksum 0x6a9b
03:03:45:254788: error-drop
rx:HundredGigabitEthernet12/0/0.501
03:03:45:254788: drop
ip6-input: drops due to concurrent reassemblies limit

This is working fine when we attach to a physical interface, however we want to 
create a bonded interface and attach bonded interface to the plugin,
This is not working and the plugin never getting hit. I tried adding the

VNET_FEATURE_INIT (ipgw_ent, static) =

{

.arc_name = "device-input",

*.node_name = "ipgw_ent",*

*.runs_before = VNET_FEATURES ("bond-input"),*

}; or "before ethernet-input", still the bonded interface is not getting catch 
and the trace looks like below.

Packet 2

*00:47:16:953591: dpdk-input*

*HundredGigabitEthernet12/0/0 rx queue 0*

buffer 0x169d81: current data 0, length 68, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x101

ext-hdr-valid

PKT MBUF: port 0, nb_segs 1, pkt_len 68

buf_len 9344, data_len 68, ol_flags 0x0, data_off 128, phys_addr 0x692760c0

packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0

rss 0x0 fdir.hi 0x0 fdir.lo 0x0

Packet Types

RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

*0x0032: 3c:2c:30:65:54:3d -> 01:00:0c:cc:cc:cd 802.1q vlan 1150 priority 7*

*00:47:16:953592: bond-input*

src 3c:2c:30:65:54:3d, dst 01:00:0c:cc:cc:cd, HundredGigabitEthernet12/0/0 -> 
BondEthernet0

00:47:16:953592: ethernet-input

0x0032: 3c:2c:30:65:54:3d -> 01:00:0c:cc:cc:cd 802.1q vlan 1150 priority 7

00:47:16:953592: llc-input

LLC snap -> snap

00:47:16:953595: snap-input

SNAP cisco per_vlan_spanning_tree

00:47:16:953596: error-drop

rx:BondEthernet0.1150

00:47:16:953596: drop

snap-input: unknown oui/snap protocol

We needed bonded interface support for "LACP/Active-backup" creation.
However our main requirement is we need to get packets to our application as 
"Raw" or "RawSocket" format, so that we can do filtering/forwarding depending 
on our own logic.
That's why we used VPP--> ourplugin--> memif-->ourapplication,
Do you have any better approach, please suggest us. Or how to attach my plugin 
to BondedInterface, anyone will solve our problem.

//Ravi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19403): https://lists.fd.io/g/vpp-dev/message/19403
Mute This Topic: https://lists.fd.io/mt/82919092/21656
Mute #vpp-memif:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-memif
Mute #vpp-hoststack:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-hoststack
Mute #vnet:https://lists.fd.io/g/vpp-dev/mutehashtag/vnet
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] missing API trace output

2021-05-18 Thread Matthew Smith via lists.fd.io

Hi Ole,

I just tested. Your patch fixes the problem. I can see gre_tunnel_add_del
and gre_tunnel_dump in a trace now.

Thanks!
-Matt


On Tue, May 18, 2021 at 4:55 AM  wrote:

> Hi Matt,
>
> Would you mind seeing if this solves the issue?
> https://gerrit.fd.io/r/c/vpp/+/32358
>
> Cheers,
> Ole
>
>
> > On 14 May 2021, at 22:04, Matthew Smith via lists.fd.io  netgate@lists.fd.io> wrote:
> >
> > Hi all,
> >
> > When I create a GRE tunnel using the API, and then try to look at an API
> trace to see exactly how it was added, the gre_tunnel_add_del message
> requesting the tunnel creation does not show up in the output. Neither do
> subsequent gre_tunnel_dump messages. The tunnels are successfully created
> and when I send a gre_tunnel_dump I receive a gre_tunnel_details, so I know
> the messages are being received and processed.
> >
> > I'm retrieving the trace by running:
> >
> > vppctl api trace save foo
> > vppctl api trace dump /tmp/foo
> >
> > The build I'm seeing this on is from a copy of master from wednesday.
> This is the last commit:
> > fd77f8c00 quic: remove cmake --target
> >
> > I poked around and tracked this down to api_global_main.api_trace_cfg
> having trace_enable set to 0 on the entries for the GRE messages:
> >
> > (gdb) p api_global_main.msg_names[1253]
> > $23 = 0x7f95985ed677 "gre_tunnel_add_del"
> > (gdb) p api_global_main.api_trace_cfg[1253]
> > $24 = {size = 0, trace_enable = 0, replay_enable = 0}
> >
> > (gdb) p api_global_main.msg_names[1255]
> > $27 = 0x7f95985ed6a3 "gre_tunnel_dump"
> > (gdb) p api_global_main.api_trace_cfg[1255]
> > $28 = {size = 0, trace_enable = 0, replay_enable = 0}
> >
> > Are the GRE messages intentionally excluded from being traced? Or is
> this an oversight?
> >
> > Thanks!
> > -Matt
> >
> >
> > 
> >
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19402): https://lists.fd.io/g/vpp-dev/message/19402
Mute This Topic: https://lists.fd.io/mt/82833140/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] Source File Paths present in VPP shared library folders

2021-05-18 Thread hemant via lists.fd.io

Nobody uses VPP from github since the repo at github does not include latest 
VPP code.  The VPP repo is stored at gerrit.  Please use the command below to 
download latest VPP.



git clone https://gerrit.fd.io/r/vpp



Hemant



From: vpp-dev@lists.fd.io  On Behalf Of C.V Jyothishmathi
Sent: Tuesday, May 18, 2021 6:45 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Source File Paths present in VPP shared library folders



Hi,



I am new to VPP. I am installing it from the github repository. I ran make 
build-release of VPP20.09 and was able to install it in my system. I had a few 
doubts. Kindly help me clarify them.



I was analyzing the binaries created by unpacking the .deb files in a tmp 
folder. When I did strings on the shared libraries created like libvppinfra.so 
and libvnet.so, I found the paths of the .c source file paths.



I had a doubt why these paths were present. Is there any way we can remove 
them?



admin@admin-server:~/test_deb/tmp2/usr/lib/x86_64-linux-gnu$ strings 
libvnet.so | grep /home/
/home/admin/vpp-20.09/build-root/install-vpp-native/vpp/lib
/home/admin/vpp-20.09/src/vnet/geneve/encap.c
/home/admin/vpp-20.09/src/vnet/bonding/node.c
/home/admin/vpp-20.09/src/vnet/ipsec/ipsec_output.c
/home/admin/vpp-20.09/src/vnet/l2/l2_api.c
/home/admin/vpp-20.09/src/vnet/vxlan/vxlan.c
/home/admin/vpp-20.09/src/vnet/geneve/geneve.c
/home/admin/vpp-20.09/src/vnet/bonding/cli.c
/home/admin/vpp-20.09/src/vnet/ip/vtep.c
/home/admin/vpp-20.09/src/vnet/vxlan-gbp/vxlan_gbp.c
/home/admin/vpp-20.09/src/vnet/vxlan-gpe/vxlan_gpe.c
/home/admin/vpp-20.09/src/vnet/lisp-cp/one_api.c
/home/admin/vpp-20.09/src/vnet/lisp-gpe/lisp_gpe_adjacency.c
/home/admin/vpp-20.09/src/vnet/srmpls/sr_mpls_policy.c
/home/admin/vpp-20.09/src/vnet/session/application_worker.c
/home/admin/vpp-20.09/src/vnet/fib/fib_attached_export.c
/home/admin/vpp-20.09/src/vnet/dpo/load_balance_map.c




Thanks!

Jyothishmathi CV



smime.p7s
Description: S/MIME cryptographic signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19401): https://lists.fd.io/g/vpp-dev/message/19401
Mute This Topic: https://lists.fd.io/mt/82908696/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Source File Paths present in VPP shared library folders

2021-05-18 Thread C.V Jyothishmathi

Hi,

I am new to VPP. I am installing it from the github repository. I ran make
build-release of VPP20.09 and was able to install it in my system. I had a
few doubts. Kindly help me clarify them.

I was analyzing the binaries created by unpacking the .deb files in a tmp
folder. When I did strings on the shared libraries created like
libvppinfra.so and libvnet.so, I found the paths of the .c source file
paths.

I had a doubt why these paths were present. Is there any way we can remove
them?

admin@admin-server:~/test_deb/tmp2/usr/lib/x86_64-linux-gnu$ strings
libvnet.so | grep /home/
/home/admin/vpp-20.09/build-root/install-vpp-native/vpp/lib
/home/admin/vpp-20.09/src/vnet/geneve/encap.c
/home/admin/vpp-20.09/src/vnet/bonding/node.c
/home/admin/vpp-20.09/src/vnet/ipsec/ipsec_output.c
/home/admin/vpp-20.09/src/vnet/l2/l2_api.c
/home/admin/vpp-20.09/src/vnet/vxlan/vxlan.c
/home/admin/vpp-20.09/src/vnet/geneve/geneve.c
/home/admin/vpp-20.09/src/vnet/bonding/cli.c
/home/admin/vpp-20.09/src/vnet/ip/vtep.c
/home/admin/vpp-20.09/src/vnet/vxlan-gbp/vxlan_gbp.c
/home/admin/vpp-20.09/src/vnet/vxlan-gpe/vxlan_gpe.c
/home/admin/vpp-20.09/src/vnet/lisp-cp/one_api.c
/home/admin/vpp-20.09/src/vnet/lisp-gpe/lisp_gpe_adjacency.c
/home/admin/vpp-20.09/src/vnet/srmpls/sr_mpls_policy.c
/home/admin/vpp-20.09/src/vnet/session/application_worker.c
/home/admin/vpp-20.09/src/vnet/fib/fib_attached_export.c
/home/admin/vpp-20.09/src/vnet/dpo/load_balance_map.c

Thanks!
Jyothishmathi CV

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19399): https://lists.fd.io/g/vpp-dev/message/19399
Mute This Topic: https://lists.fd.io/mt/82908696/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] missing API trace output

2021-05-18 Thread Ole Troan

Hi Matt,

Would you mind seeing if this solves the issue?
https://gerrit.fd.io/r/c/vpp/+/32358

Cheers,
Ole


> On 14 May 2021, at 22:04, Matthew Smith via lists.fd.io 
>  wrote:
> 
> Hi all,
> 
> When I create a GRE tunnel using the API, and then try to look at an API 
> trace to see exactly how it was added, the gre_tunnel_add_del message 
> requesting the tunnel creation does not show up in the output. Neither do 
> subsequent gre_tunnel_dump messages. The tunnels are successfully created and 
> when I send a gre_tunnel_dump I receive a gre_tunnel_details, so I know the 
> messages are being received and processed.
> 
> I'm retrieving the trace by running:
> 
> vppctl api trace save foo
> vppctl api trace dump /tmp/foo
> 
> The build I'm seeing this on is from a copy of master from wednesday. This is 
> the last commit:
> fd77f8c00 quic: remove cmake --target
> 
> I poked around and tracked this down to api_global_main.api_trace_cfg having 
> trace_enable set to 0 on the entries for the GRE messages:
> 
> (gdb) p api_global_main.msg_names[1253]
> $23 = 0x7f95985ed677 "gre_tunnel_add_del"
> (gdb) p api_global_main.api_trace_cfg[1253]
> $24 = {size = 0, trace_enable = 0, replay_enable = 0}
> 
> (gdb) p api_global_main.msg_names[1255]
> $27 = 0x7f95985ed6a3 "gre_tunnel_dump"
> (gdb) p api_global_main.api_trace_cfg[1255]
> $28 = {size = 0, trace_enable = 0, replay_enable = 0}
> 
> Are the GRE messages intentionally excluded from being traced? Or is this an 
> oversight?
> 
> Thanks!
> -Matt
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19398): https://lists.fd.io/g/vpp-dev/message/19398
Mute This Topic: https://lists.fd.io/mt/82833140/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] [DPDK] AF_XDP PMD

2021-05-18 Thread Benoit Ganne (bganne) via lists.fd.io

> I’m not very familiar with DPDK AF_XDP pmd, but my guess is that if it is
> not working, likely it is because it needs to do something special with
> buffer memory (i.e. register regions trough AFXDP APIs) and that memory is
> handled by VPP.

Damjan is correct, we rely on AF_XDP unaligned memory support, I do not know 
whether DPDK initializes it or not.
Did you try to use AF_XDP DPDK PMD and is it failing?

ben

> > On 18.05.2021., at 11:25, Catalin Vasile  wrote:
> >
> > So shouldn't this hack for also using the vpp buffer manager be
> generally usable with all PMDs?
> > From: Damjan Marion 
> > Sent: Tuesday, May 18, 2021 1:17
> > To: Catalin Vasile 
> > Cc: vpp-dev@lists.fd.io 
> > Subject: Re: [vpp-dev] [DPDK] AF_XDP PMD
> >
> >
> > No, dpdk PMDs are also using vpp buffer manager, we are cheating a bit
> by registering fake mempool.
> >
> > —
> > Damjan
> >
> > > On 17.05.2021., at 23:40, Catalin Vasile  wrote:
> > >
> > > �쏜㷃�쏜㷃�쏜㋢鹋ᢢ燨꽹ꥥ駫ⱪެ뇩譡諈⮢觬㽅죩瞵皆�돿쭬緘ꣾ࿯ꚗ庿咽닆ꁻﵽ�貺
> 힓蘫Ꭲ颜蛛榳￥請汽�﹫翳漷㛿껹蚮让㬉�響痫ﺣ৞깘겶쟝誅➲犸魺᭭ꛏﾖ⬭뇷抣뺚嵺￮黋魶暫誉
> 쨦�쏜㷃�쏜㷃�쏜
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19397): https://lists.fd.io/g/vpp-dev/message/19397
Mute This Topic: https://lists.fd.io/mt/82836782/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] [DPDK] AF_XDP PMD

2021-05-18 Thread Damjan Marion via lists.fd.io

Our preference is to have native drivers, that is what we did already for many 
devices.
DPDK is not modular so each time you want ot use some DPDK feature end up with 
sub optimal solution.
Notable exception is DPDK crypto which allows use of crypto PMDs without being 
forced to use mbufs, etc...

I’m not very familiar with DPDK AF_XDP pmd, but my guess is that if it is not 
working, likely it is because it needs to do something special with buffer 
memory (i.e. register regions trough AFXDP APIs) and that memory is handled by 
VPP.

> On 18.05.2021., at 11:25, Catalin Vasile  wrote:
> 
> So shouldn't this hack for also using the vpp buffer manager be generally 
> usable with all PMDs?
> From: Damjan Marion 
> Sent: Tuesday, May 18, 2021 1:17
> To: Catalin Vasile 
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] [DPDK] AF_XDP PMD
>  
> 
> No, dpdk PMDs are also using vpp buffer manager, we are cheating a bit by 
> registering fake mempool.
> 
> — 
> Damjan
> 
> > On 17.05.2021., at 23:40, Catalin Vasile  wrote:
> > 
> > �쏜㷃�쏜㷃�쏜㋢鹋ᢢ燨꽹ꥥ駫ⱪެ뇩譡諈⮢觬㽅죩瞵皆�돿쭬緘ꣾ࿯ꚗ庿咽닆ꁻﵽ�貺힓蘫Ꭲ颜蛛榳￥請汽�﹫翳漷㛿껹蚮让㬉�響痫ﺣ৞깘겶쟝誅➲犸魺᭭ꛏﾖ⬭뇷抣뺚嵺￮黋魶暫誉쨦�쏜㷃�쏜㷃�쏜

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19396): https://lists.fd.io/g/vpp-dev/message/19396
Mute This Topic: https://lists.fd.io/mt/82836782/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] [DPDK] AF_XDP PMD

2021-05-18 Thread Catalin Vasile

So shouldn't this hack for also using the vpp buffer manager be generally 
usable with all PMDs?

From: Damjan Marion 
Sent: Tuesday, May 18, 2021 1:17
To: Catalin Vasile 
Cc: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] [DPDK] AF_XDP PMD


No, dpdk PMDs are also using vpp buffer manager, we are cheating a bit by 
registering fake mempool.

—
Damjan

> On 17.05.2021., at 23:40, Catalin Vasile  wrote:
>
> �쏜㷃�쏜㷃�쏜㋢鹋ᢢ燨꽹ꥥ駫ⱪެ뇩譡諈⮢觬㽅죩瞵皆�돿쭬緘ꣾ࿯ꚗ庿咽닆ꁻﵽ�貺힓蘫Ꭲ颜蛛榳￥請汽�﹫翳漷㛿껹蚮让㬉�響痫ﺣ৞깘겶쟝誅➲犸魺᭭ꛏﾖ⬭뇷抣뺚嵺￮黋魶暫誉쨦�쏜㷃�쏜㷃�쏜

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19395): https://lists.fd.io/g/vpp-dev/message/19395
Mute This Topic: https://lists.fd.io/mt/82836782/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] missing API trace output

2021-05-18 Thread Ole Troan

Hi Matt,

Might be an oversight in code auto-generation. Looking.

Cheers,
Ole

> On 14 May 2021, at 22:04, Matthew Smith via lists.fd.io 
>  wrote:
> 
> Hi all,
> 
> When I create a GRE tunnel using the API, and then try to look at an API 
> trace to see exactly how it was added, the gre_tunnel_add_del message 
> requesting the tunnel creation does not show up in the output. Neither do 
> subsequent gre_tunnel_dump messages. The tunnels are successfully created and 
> when I send a gre_tunnel_dump I receive a gre_tunnel_details, so I know the 
> messages are being received and processed.
> 
> I'm retrieving the trace by running:
> 
> vppctl api trace save foo
> vppctl api trace dump /tmp/foo
> 
> The build I'm seeing this on is from a copy of master from wednesday. This is 
> the last commit:
> fd77f8c00 quic: remove cmake --target
> 
> I poked around and tracked this down to api_global_main.api_trace_cfg having 
> trace_enable set to 0 on the entries for the GRE messages:
> 
> (gdb) p api_global_main.msg_names[1253]
> $23 = 0x7f95985ed677 "gre_tunnel_add_del"
> (gdb) p api_global_main.api_trace_cfg[1253]
> $24 = {size = 0, trace_enable = 0, replay_enable = 0}
> 
> (gdb) p api_global_main.msg_names[1255]
> $27 = 0x7f95985ed6a3 "gre_tunnel_dump"
> (gdb) p api_global_main.api_trace_cfg[1255]
> $28 = {size = 0, trace_enable = 0, replay_enable = 0}
> 
> Are the GRE messages intentionally excluded from being traced? Or is this an 
> oversight?
> 
> Thanks!
> -Matt
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19394): https://lists.fd.io/g/vpp-dev/message/19394
Mute This Topic: https://lists.fd.io/mt/82833140/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Maximum support in vpp

[vpp-dev] plugin to filter packets

[vpp-dev] Plugin and getting packets from Bonded interface. #vpp-memif #vpp-hoststack #vnet

Re: [vpp-dev] missing API trace output

Re: [vpp-dev] Source File Paths present in VPP shared library folders

[vpp-dev] Source File Paths present in VPP shared library folders

Re: [vpp-dev] missing API trace output

Re: [vpp-dev] [DPDK] AF_XDP PMD

Re: [vpp-dev] [DPDK] AF_XDP PMD

Re: [vpp-dev] [DPDK] AF_XDP PMD

Re: [vpp-dev] missing API trace output

11 matches

Site Navigation

Mail list logo

Footer information