Re: [vpp-dev] Q: how best to avoid locking for cleanup.
> Subject: Re: [vpp-dev] Q: how best to avoid locking for cleanup.
>
> On 2/28/20, Honnappa Nagarahalli wrote:
>
> >> On the other hand, if you do modify shared data structures in the
> >> datapath, you are on your own - you need to take care of the data
> >> consistency.
> >> Again, the way we usually deal with that is to do a "rpc" to the main
> >> thread - then the main thread can request the worker barrier, etc.
> >>
> >> Or do you refer to other situations?
> > I was looking at the bi-hash library on a standalone basis. The
> > entries are deleted and buckets are freed without any synchronization
> > between the writer
>
> FWIW, the above statement is incorrect if all we are talking is pure bihash
> operation with values that are not used as keys for subsequent memory
> accesses in other data structures. This code in
Yes, pure bihash operations, not interconnected to another data structure.
> include/vppinfra/bihash_template.c might be of interest:
>
> static inline int BV (clib_bihash_add_del_inline)
> (BVT (clib_bihash) * h, BVT (clib_bihash_kv) * add_v, int is_add,
>int (*is_stale_cb) (BVT (clib_bihash_kv) *, void *), void *arg) {
> u32 bucket_index;
>
> ...
>
>
> BV (clib_bihash_lock_bucket) (b); <- LOCK
>
> /* First elt in the bucket? */
> if (BV (clib_bihash_bucket_is_empty) (b))
> {
> if (is_add == 0)
> {
> BV (clib_bihash_unlock_bucket) (b);
> return (-1);
> }
>
>
>
> /* Move readers to a (locked) temp copy of the bucket */
> BV (clib_bihash_alloc_lock) (h);<- LOCK
> BV (make_working_copy) (h, b);
>
> -
>
> and so on.
Yes, those locks provide writer-writer concurrency. There is no issue here.
>
> when performing the actual bihash operations as a user of the bihash, you
> most definitely do *not* need any extra locking, the bihash is doing it for
> you
> behind the scenes.
Yes, if these operations are writer operations.
>
> There is only one transient condition that I had seen - under intense
> add/delete workload, the readers in other threads may see the lookup
> successful but the value returned being ~0.
This is the reader-writer concurrency. This is the issue I am talking about.
This can happen without intense add/delete workload. The return value contains
keys and value. So, the return value may be a mix of ~0 and previous values.
Also, while freeing the bucket on the writer, the readers might still be
accessing the bucket.
> That is fairly easy to deal with.
Are you thinking of the same solution as Dave suggested?
>
> But of course there is a race in case you are using bihash to store secondary
> indices into your own data structures - if you are deleting a bihash entry,
> another thread may have *just* made a lookup, obtained the index, and is
> using that index, so for that part you do need to take care of by yourself,
> indeed.
>
> --a
>
> > and the data plane threads. If the synchronization is handled outside
> > of this library using 'worker barrier' it should be alright.
> >
> >>
> >> Best
> >> Ben
> >>
> >> > -Original Message-
> >> > From: vpp-dev@lists.fd.io On Behalf Of
> >> > Honnappa Nagarahalli
> >> > Sent: jeudi 27 février 2020 17:51
> >> > To: cho...@chopps.org; vpp-dev@lists.fd.io; Honnappa Nagarahalli
> >> >
> >> > Cc: nd
> >> > Subject: Re: [vpp-dev] Q: how best to avoid locking for cleanup.
> >> >
> >> > I think there are similar issues in bi-hash (i.e. the entry could
> >> > be deleted from control plane while the data plane threads are
> >> > doing the lookup).
> >> >
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Honnappa
> >> >
> >> >
> >> >
> >> > From: vpp-dev@lists.fd.io On Behalf Of
> >> > Christian Hopps via Lists.Fd.Io
> >> > Sent: Thursday, February 27, 2020 5:09 AM
> >> > To: vpp-dev
> >> > Cc: vpp-dev@lists.fd.io
> >> > Subject: Re: [vpp-dev] Q: how best to avoid locking for cleanup.
> >> >
> >> >
> >> >
> >> > I received a private message indicating that one solution was to
> >> > just wait "long enough" for the packets to drain. This is the
> >> > method I'm going to go with as it's simple (albeit not as
> >> > deterministic as some marking/callback scheme :)
> >> >
> >> > For my case I think I can wait ridiculously long for "long enough"
> >> > and just have a process do garbage collection after a full second.
> >> >
> >> > I do wonder how many other cases of "state associated with
> >> > in-flight packets" there might be, and if more sophisticated
> >> > general solution might be useful.
> >> >
> >> > Thanks,
> >> > Chris.
> >> >
> >> > > On Feb 25, 2020, at 6:27 PM, Christian Hopps >> > > wrote:
> >> > >
> >> > > I've got a (hopefully) interesting problem with locking in VPP.
> >> > >
> >> > > I need to add some cleanup code to my IPTFS additions to ipsec.
> >> > Basically I have some per-SA queues that I need to cleanup when an
> >> > SA is deleted.
> >> > >
> >> > > -
Re: [vpp-dev] Q: how best to avoid locking for cleanup.
On the data plane side, please use vm->main_loop_count. Mark the variable
volatile in src/vlib/main.h.
Atomically update data structures, include a memory barrier.
Foreach_thread: snapshoot vm->main_loop_count.
Delay until all vm->main_loop_count values have changed.
Clean up old data structures.
FWIW... Dave
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Govindarajan
Mohandoss
Sent: Friday, February 28, 2020 4:55 PM
To: Andrew Yourtchenko ; Honnappa Nagarahalli
Cc: Benoit Ganne (bganne) ; cho...@chopps.org;
vpp-dev@lists.fd.io; nd ; Lijian Zhang
Subject: Re: [vpp-dev] Q: how best to avoid locking for cleanup.
Hi Chris,
I do wonder how many other cases of "state associated with
in-flight packets" there might be, and if more sophisticated
general solution might be useful.
> RCU mechanism is the general solution to avoid Reader locks in data
> plane. With this scheme, there is no lock needed in the data plane. The
> in-flight packets can be tracked through the counters like the way you
> described (or) through an alternate scheme explained below. The control
> plane can do a delayed free of the shared memory objects (Shared with
> data plane) based on these counters.
If the scope of the counters are widened across the entire packet processing
path in run to completion model, then all the data structures like Bihash,
IPSec SA and other unknown cases can be covered.
Proposal:
===
Control Plane:
===
1. Maintain a common running counter across all the control plane threads.
2. Delete the shared memory objects from Bihash/IPSec SA table.
3. Set the running counter in shared memory.
4. Wait till all the data plane threads catch up with this counter value
(Maintain a catch up counter per data plane thread).
Optimization Note: Instead of waiting for data plane sync, a pending list
can be maintained to hold the memory objects that needs to be freed after all
the inflight packets are flushed out.
The memory objects in the Pending list
can then be freed through next data plane table entry add/delete APIs.
5. Free the shared memory objects once all the data plane threads catch up.
In Fast path:
==
While (1) /* packet processing loop in run-to-completion model */ {
Ethernet processing,
IP Processing,
IPSec Processing,
Etc.,
/* End of packet processing */
Catch up counter = counter value set by control plane. Data
plane/Control plane sync }
There is a solution to this problem already in DPDK. We can evaluate it and
decide whether it will fit VPP requirements (or) we can do a new design for VPP.
https://doc.dpdk.org/guides/prog_guide/rcu_lib.html
Thanks
Govind
> -Original Message-
> From: Andrew Yourtchenko
> Sent: Friday, February 28, 2020 5:50 AM
> To: Honnappa Nagarahalli
> Cc: Benoit Ganne (bganne) ; cho...@chopps.org; vpp-
> d...@lists.fd.io; nd ; Govindarajan Mohandoss
> ; Lijian Zhang
> Subject: Re: [vpp-dev] Q: how best to avoid locking for cleanup.
>
> On 2/28/20, Honnappa Nagarahalli
> wrote:
>
> >> On the other hand, if you do modify shared data structures in the
> >> datapath, you are on your own - you need to take care of the data
> >> consistency.
> >> Again, the way we usually deal with that is to do a "rpc" to the
> >> main thread - then the main thread can request the worker barrier, etc.
> >>
> >> Or do you refer to other situations?
> > I was looking at the bi-hash library on a standalone basis. The
> > entries are deleted and buckets are freed without any
> > synchronization between the writer
>
> FWIW, the above statement is incorrect if all we are talking is pure
> bihash operation with values that are not used as keys for subsequent
> memory accesses in other data structures. This code in
> include/vppinfra/bihash_template.c might be of interest:
>
> static inline int BV (clib_bihash_add_del_inline)
> (BVT (clib_bihash) * h, BVT (clib_bihash_kv) * add_v, int is_add,
>int (*is_stale_cb) (BVT (clib_bihash_kv) *, void *), void *arg) {
> u32 bucket_index;
>
> ...
>
>
> BV (clib_bihash_lock_bucket) (b); <- LOCK
>
> /* First elt in the bucket? */
> if (BV (clib_bihash_bucket_is_empty) (b))
> {
> if (is_add == 0)
> {
> BV (clib_bihash_unlock_bucket) (b);
> return (-1);
> }
>
>
>
> /* Move readers to a (locked) temp copy of the bucket */
> BV (clib_bihash_alloc_lock) (h);<- LOCK
> BV (make_working_copy) (h, b);
>
> -
>
> and so on.
>
> when performing the actual bihash operations as a user of the bihash,
> you most definitely do *not* need any extra locking, the bihash is
> doing it for you behind the scenes.
>
> There is only one transient condition that I had seen - under intense
> add/delete workload, the readers in other threads may see the lookup
>
Re: [vpp-dev] Q: how best to avoid locking for cleanup.
Hi Chris,
I do wonder how many other cases of "state associated with
in-flight packets" there might be, and if more sophisticated
general solution might be useful.
> RCU mechanism is the general solution to avoid Reader locks in data
> plane. With this scheme, there is no lock needed in the data plane. The
> in-flight packets can be tracked through the counters like the way you
> described (or) through an alternate scheme explained below. The control
> plane can do a delayed free of the shared memory objects (Shared with
> data plane) based on these counters.
If the scope of the counters are widened across the entire packet processing
path in run to completion model, then all the data structures like Bihash,
IPSec SA and other unknown cases can be covered.
Proposal:
===
Control Plane:
===
1. Maintain a common running counter across all the control plane threads.
2. Delete the shared memory objects from Bihash/IPSec SA table.
3. Set the running counter in shared memory.
4. Wait till all the data plane threads catch up with this counter value
(Maintain a catch up counter per data plane thread).
Optimization Note: Instead of waiting for data plane sync, a pending list
can be maintained to hold the memory objects that needs to be freed after all
the inflight packets are flushed out.
The memory objects in the Pending list
can then be freed through next data plane table entry add/delete APIs.
5. Free the shared memory objects once all the data plane threads catch up.
In Fast path:
==
While (1) /* packet processing loop in run-to-completion model */
{
Ethernet processing,
IP Processing,
IPSec Processing,
Etc.,
/* End of packet processing */
Catch up counter = counter value set by control plane. Data
plane/Control plane sync
}
There is a solution to this problem already in DPDK. We can evaluate it and
decide whether it will fit VPP requirements (or) we can do a new design for VPP.
https://doc.dpdk.org/guides/prog_guide/rcu_lib.html
Thanks
Govind
> -Original Message-
> From: Andrew Yourtchenko
> Sent: Friday, February 28, 2020 5:50 AM
> To: Honnappa Nagarahalli
> Cc: Benoit Ganne (bganne) ; cho...@chopps.org; vpp-
> d...@lists.fd.io; nd ; Govindarajan Mohandoss
> ; Lijian Zhang
> Subject: Re: [vpp-dev] Q: how best to avoid locking for cleanup.
>
> On 2/28/20, Honnappa Nagarahalli
> wrote:
>
> >> On the other hand, if you do modify shared data structures in the
> >> datapath, you are on your own - you need to take care of the data
> >> consistency.
> >> Again, the way we usually deal with that is to do a "rpc" to the main
> >> thread - then the main thread can request the worker barrier, etc.
> >>
> >> Or do you refer to other situations?
> > I was looking at the bi-hash library on a standalone basis. The
> > entries are deleted and buckets are freed without any synchronization
> > between the writer
>
> FWIW, the above statement is incorrect if all we are talking is pure bihash
> operation with values that are not used as keys for subsequent memory
> accesses in other data structures. This code in
> include/vppinfra/bihash_template.c might be of interest:
>
> static inline int BV (clib_bihash_add_del_inline)
> (BVT (clib_bihash) * h, BVT (clib_bihash_kv) * add_v, int is_add,
>int (*is_stale_cb) (BVT (clib_bihash_kv) *, void *), void *arg) {
> u32 bucket_index;
>
> ...
>
>
> BV (clib_bihash_lock_bucket) (b); <- LOCK
>
> /* First elt in the bucket? */
> if (BV (clib_bihash_bucket_is_empty) (b))
> {
> if (is_add == 0)
> {
> BV (clib_bihash_unlock_bucket) (b);
> return (-1);
> }
>
>
>
> /* Move readers to a (locked) temp copy of the bucket */
> BV (clib_bihash_alloc_lock) (h);<- LOCK
> BV (make_working_copy) (h, b);
>
> -
>
> and so on.
>
> when performing the actual bihash operations as a user of the bihash, you
> most definitely do *not* need any extra locking, the bihash is doing it for
> you
> behind the scenes.
>
> There is only one transient condition that I had seen - under intense
> add/delete workload, the readers in other threads may see the lookup
> successful but the value returned being ~0.
> That is fairly easy to deal with.
>
> But of course there is a race in case you are using bihash to store secondary
> indices into your own data structures - if you are deleting a bihash entry,
> another thread may have *just* made a lookup, obtained the index, and is
> using that index, so for that part you do need to take care of by yourself,
> indeed.
>
> --a
>
> > and the data plane threads. If the synchronization is handled outside
> > of this library using 'worker barrier' it should be alright.
> >
> >>
> >> Best
> >> Ben
> >>
> >> > -Original Message-
> >> > From: vpp-dev@lists.fd.io On Behalf Of
> >> >
Re: [vpp-dev] conditional compile based on API version?
OK, updated patch. Please review: https://gerrit.fd.io/r/c/vpp/+/25540 Best regards, Ole > On 28 Feb 2020, at 17:49, Ole Troan wrote: > > Christian, > > OK, can update to > #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ > > Just to be clear, > you don't use this on the VPP side, but on the client side right? > So if VAPI client wrapper provided this define, that would be fine too? > > Cheers, > Ole > >> On 28 Feb 2020, at 16:56, Christian Hopps wrote: >> >> This would be great, but how about these defines get generated (e.g., for >> ipsec.api with version "3.2.1") >> >> #define IPSEC_API_SEMVER_MAJOR 3 >> #define IPSEC_API_SEMVER_MINOR 2 >> #define IPSEC_API_SEMVER_FIX 1 >> #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ >> >> The last define is all that's really needed though. >> >> Then one can do this in code: >> >> #if (IPSEC_API_SERVER < 400) && (IPSEC_API_SEMVER >= 3002000) >> >> /* use an API introduced in ipsec.api verion 3.2.0 */ >> >> #elif (IPSEC_API_SERVER >= 400) && (IPSEC_API_SERVER < 500) >> >> /* use the same API call whose definition changed in 4.0.0 */ >> >> #else >> #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x >> #endif >> >> The other defines just make this a little cleaner looking: >> >> #if IPSEC_API_SERVER_MAJOR == 3 && IPSEC_API_SEMVER_MINOR >= 2 >> >> /* use an API introduced in ipsec.api verion 3.2.0 */ >> >> #elif IPSEC_API_SERVER_MAJOR == 4 >> >> /* use the same API call whose definition changed in 4.0.0 */ >> >> #else >> #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x >> #endif >> >> Thanks, >> Chris. >> >>> On Feb 28, 2020, at 7:36 AM, otr...@employees.org wrote: >>> >>> Christian, >>> How does one conditionally compile code based on the API version? I was looking for a compile time conditional I could then use #if's with, but I can't seem to find one. A release version #define would work too, although not be as nice as the per file semver one. I did find these are generated: #ifdef vl_api_version_tuple vl_api_version_tuple(ipsec.api, 3, 0, 0) #endif /* vl_api_version_tuple */ but I dont know how to utilize this during CPP in an #if conditional >>> >>> that functions is used like this: >>> #define vl_api_version_tuple(n,mj, mi, p) \ >>> vl_msg_api_add_version (am, #n, mj, mi, p); >>> #include >>> #undef vl_api_version_tuple >>> >>> But if you want a simple define to use I can trivially add something like: >>> #define _SEMVER 1 >>> >>> Could go in .api_types.h >>> >>> Cheers, >>> Ole >> > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15629): https://lists.fd.io/g/vpp-dev/message/15629 Mute This Topic: https://lists.fd.io/mt/71604387/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 with FRR Bring-up - not able to enable tap-inject
“show plugin” will tell you which plugins are loaded. Note that the .so files must be located in the same directory with all of the other plugins. Find “dpdk_plugin.so”, etc. D. From: vpp-dev@lists.fd.io On Behalf Of Majumdar, Kausik Sent: Friday, February 28, 2020 3:53 PM To: Balaji Venkatraman (balajiv) ; vpp-dev Cc: vppsb-...@lists.fd.io; Majumdar, Kausik Subject: Re: [vpp-dev] VPP with FRR Bring-up - not able to enable tap-inject Hi folks, I have made some code changes in VPPSB (the code changes are attached here), with these changes I have re-compiled. I was able to successfully compiled vpp with the netlink and router plugins. I have verified the router plugin contains the correct symbols to enable tap-inject interface. But still can’t enable tap-inject in VPP. I have stopped and started the VPP service. I am guessing that VPP is not loading these two plugins. I would appreciate if you have any workaround or suggestion to load VPP with the router and netlink plugins. [root@localhost install-vpp-native]# ls netlink/lib64/ librtnl.a librtnl.solibrtnl.so.0.0.0 testrtnl_plugin.la testrtnl_plugin.so.0 librtnl.la librtnl.so.0 testrtnl_plugin.a testrtnl_plugin.so testrtnl_plugin.so.0.0.0 [root@localhost install-vpp-native]# ls router/ include lib64 [root@localhost install-vpp-native]# ls router/lib64/ router.a router.la router.so router.so.0 router.so.0.0.0 [root@localhost install-vpp-native]# 36: 0 FILELOCAL DEFAULT ABS tap_inject.c 37: 256536 FUNCLOCAL DEFAULT 11 tap_inject_is_enabled 38: 258936 FUNCLOCAL DEFAULT 11 tap_inject_is_config_enabled 39: 25ad36 FUNCLOCAL DEFAULT 11 tap_inject_is_config_disabled 40: 002106a088 OBJECT LOCAL DEFAULT 25 tap_inject_main 41: 33ba70 FUNCLOCAL DEFAULT 11 tap_inject_disable 43: 3400 579 FUNCLOCAL DEFAULT 11 tap_inject_enable 44: 3643 771 FUNCLOCAL DEFAULT 11 tap_inject_iface_isr 45: 00210220 120 OBJECT LOCAL DEFAULT 23 tap_inject_iface_isr_node 46: 3946 103 FUNCLOCAL DEFAULT 11 __vlib_add_node_registration_tap_inject_iface_isr_node 47: 39ad 195 FUNCLOCAL DEFAULT 11 __vlib_rm_node_registration_tap_inject_iface_isr_node 48: 3a70 2018 FUNCLOCAL DEFAULT 11 tap_inject_interface_add_del 49: 425269 FUNCLOCAL DEFAULT 11 __vnet_interface_function_init_hw_interface_add_del_tap_inject_interface_add_del 51: 4297 155 FUNCLOCAL DEFAULT 11 __vnet_interface_function_deinit_hw_interface_add_del_tap_inject_interface_add_del 52: 4332 1412 FUNCLOCAL DEFAULT 11 tap_inject_enable_disable_all_interfaces 54: 48b6 182 FUNCLOCAL DEFAULT 11 tap_inject_cli 56: 002102a0 104 OBJECT LOCAL DEFAULT 23 tap_inject_enable_cmd 57: 496c 111 FUNCLOCAL DEFAULT 11 __vlib_cli_command_registration_tap_inject_enable_cmd 58: 49db 200 FUNCLOCAL DEFAULT 11 __vlib_cli_command_unregistration_tap_inject_enable_cmd 59: 00210320 104 OBJECT LOCAL DEFAULT 23 tap_inject_disable_cmd 60: 4aa3 111 FUNCLOCAL DEFAULT 11 __vlib_cli_command_registration_tap_inject_disable_cmd 61: 4b12 200 FUNCLOCAL DEFAULT 11 __vlib_cli_command_unregistration_tap_inject_disable_cmd 62: 4bda 1026 FUNCLOCAL DEFAULT 11 show_tap_inject 63: 002103a0 104 OBJECT LOCAL DEFAULT 23 show_tap_inject_cmd 64: 4fdc 111 FUNCLOCAL DEFAULT 11 __vlib_cli_command_registration_show_tap_inject_cmd 65: 504b 200 FUNCLOCAL DEFAULT 11 __vlib_cli_command_unregistration_show_tap_inject_cmd 66: 5113 404 FUNCLOCAL DEFAULT 11 tap_inject_config 68: 52a7 107 FUNCLOCAL DEFAULT 11 __vlib_add_config_function_tap_inject_config 69: 5312 195 FUNCLOCAL DEFAULT 11 __vlib_rm_config_function_tap_inject_config 70: 0 FILELOCAL DEFAULT ABS tap_inject_netlink.c 78: 0 FILELOCAL DEFAULT ABS tap_inject_node.c [root@localhost build-root]# systemctl status vpp ● vpp.service - Vector Packet Processing Process Loaded: loaded (/usr/lib/systemd/system/vpp.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2020-02-27 19:33:26 PST; 16h ago Process: 16266 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, status=0/SUCCESS) Process: 16264 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm /dev/shm/vpe-api (code=exited, status=0/SUCCESS) Main PID: 16270 (vpp_main) Tasks: 2 CGroup: /system.slice/vpp.service └─16270 /usr/bin/vpp
Re: [vpp-dev] VPP with FRR Bring-up - not able to enable tap-inject
Hi folks, I have made some code changes in VPPSB (the code changes are attached here), with these changes I have re-compiled. I was able to successfully compiled vpp with the netlink and router plugins. I have verified the router plugin contains the correct symbols to enable tap-inject interface. But still can’t enable tap-inject in VPP. I have stopped and started the VPP service. I am guessing that VPP is not loading these two plugins. I would appreciate if you have any workaround or suggestion to load VPP with the router and netlink plugins. [root@localhost install-vpp-native]# ls netlink/lib64/ librtnl.a librtnl.solibrtnl.so.0.0.0 testrtnl_plugin.la testrtnl_plugin.so.0 librtnl.la librtnl.so.0 testrtnl_plugin.a testrtnl_plugin.so testrtnl_plugin.so.0.0.0 [root@localhost install-vpp-native]# ls router/ include lib64 [root@localhost install-vpp-native]# ls router/lib64/ router.a router.la router.so router.so.0 router.so.0.0.0 [root@localhost install-vpp-native]# 36: 0 FILELOCAL DEFAULT ABS tap_inject.c 37: 256536 FUNCLOCAL DEFAULT 11 tap_inject_is_enabled 38: 258936 FUNCLOCAL DEFAULT 11 tap_inject_is_config_enabled 39: 25ad36 FUNCLOCAL DEFAULT 11 tap_inject_is_config_disabled 40: 002106a088 OBJECT LOCAL DEFAULT 25 tap_inject_main 41: 33ba70 FUNCLOCAL DEFAULT 11 tap_inject_disable 43: 3400 579 FUNCLOCAL DEFAULT 11 tap_inject_enable 44: 3643 771 FUNCLOCAL DEFAULT 11 tap_inject_iface_isr 45: 00210220 120 OBJECT LOCAL DEFAULT 23 tap_inject_iface_isr_node 46: 3946 103 FUNCLOCAL DEFAULT 11 __vlib_add_node_registration_tap_inject_iface_isr_node 47: 39ad 195 FUNCLOCAL DEFAULT 11 __vlib_rm_node_registration_tap_inject_iface_isr_node 48: 3a70 2018 FUNCLOCAL DEFAULT 11 tap_inject_interface_add_del 49: 425269 FUNCLOCAL DEFAULT 11 __vnet_interface_function_init_hw_interface_add_del_tap_inject_interface_add_del 51: 4297 155 FUNCLOCAL DEFAULT 11 __vnet_interface_function_deinit_hw_interface_add_del_tap_inject_interface_add_del 52: 4332 1412 FUNCLOCAL DEFAULT 11 tap_inject_enable_disable_all_interfaces 54: 48b6 182 FUNCLOCAL DEFAULT 11 tap_inject_cli 56: 002102a0 104 OBJECT LOCAL DEFAULT 23 tap_inject_enable_cmd 57: 496c 111 FUNCLOCAL DEFAULT 11 __vlib_cli_command_registration_tap_inject_enable_cmd 58: 49db 200 FUNCLOCAL DEFAULT 11 __vlib_cli_command_unregistration_tap_inject_enable_cmd 59: 00210320 104 OBJECT LOCAL DEFAULT 23 tap_inject_disable_cmd 60: 4aa3 111 FUNCLOCAL DEFAULT 11 __vlib_cli_command_registration_tap_inject_disable_cmd 61: 4b12 200 FUNCLOCAL DEFAULT 11 __vlib_cli_command_unregistration_tap_inject_disable_cmd 62: 4bda 1026 FUNCLOCAL DEFAULT 11 show_tap_inject 63: 002103a0 104 OBJECT LOCAL DEFAULT 23 show_tap_inject_cmd 64: 4fdc 111 FUNCLOCAL DEFAULT 11 __vlib_cli_command_registration_show_tap_inject_cmd 65: 504b 200 FUNCLOCAL DEFAULT 11 __vlib_cli_command_unregistration_show_tap_inject_cmd 66: 5113 404 FUNCLOCAL DEFAULT 11 tap_inject_config 68: 52a7 107 FUNCLOCAL DEFAULT 11 __vlib_add_config_function_tap_inject_config 69: 5312 195 FUNCLOCAL DEFAULT 11 __vlib_rm_config_function_tap_inject_config 70: 0 FILELOCAL DEFAULT ABS tap_inject_netlink.c 78: 0 FILELOCAL DEFAULT ABS tap_inject_node.c [root@localhost build-root]# systemctl status vpp ● vpp.service - Vector Packet Processing Process Loaded: loaded (/usr/lib/systemd/system/vpp.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2020-02-27 19:33:26 PST; 16h ago Process: 16266 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, status=0/SUCCESS) Process: 16264 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm /dev/shm/vpe-api (code=exited, status=0/SUCCESS) Main PID: 16270 (vpp_main) Tasks: 2 CGroup: /system.slice/vpp.service └─16270 /usr/bin/vpp -c /etc/vpp/startup.conf Feb 27 19:33:31 localhost.localdomain vnet[16270]: dpdk_ipsec_process:1014: not enough DPDK crypto resources, default to OpenSSL Feb 27 19:34:00 localhost.localdomain vnet[16270]: enable: unknown input `tap-inject Feb 27 19:34:26 localhost.localdomain vnet[16270]: enable: unknown input ` Feb 27 19:34:45 localhost.localdomain vnet[16270]: enable: unknown input `tap-inject Feb 27 19:36:19 localhost.localdomain
Re: [vpp-dev] conditional compile based on API version?
> On Feb 28, 2020, at 2:40 PM, Christian Hopps wrote: > > > >> On Feb 28, 2020, at 11:49 AM, Ole Troan wrote: >> >> Christian, >> >> OK, can update to >> #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ >> >> Just to be clear, >> you don't use this on the VPP side, but on the client side right? > > Correct, it's for things like supporting VPP as an option in other open > source projects like strongswan. > >> So if VAPI client wrapper provided this define, that would be fine too? > > I could include the vapi header to get to the define, sure. > > [ I don't actually use VAPI in my stuff b/c I don't want to have to define > callbacks for every sync API function I use. :) ] FWIW I don't think I'm alone in not using VAPI, so it would be more natural if the version define was also available in the normal API location as well. :) Thanks, Chris. > > Thanks, > Chris. > >> >> Cheers, >> Ole >> >>> On 28 Feb 2020, at 16:56, Christian Hopps wrote: >>> >>> This would be great, but how about these defines get generated (e.g., for >>> ipsec.api with version "3.2.1") >>> >>> #define IPSEC_API_SEMVER_MAJOR 3 >>> #define IPSEC_API_SEMVER_MINOR 2 >>> #define IPSEC_API_SEMVER_FIX 1 >>> #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ >>> >>> The last define is all that's really needed though. >>> >>> Then one can do this in code: >>> >>> #if (IPSEC_API_SERVER < 400) && (IPSEC_API_SEMVER >= 3002000) >>> >>> /* use an API introduced in ipsec.api verion 3.2.0 */ >>> >>> #elif (IPSEC_API_SERVER >= 400) && (IPSEC_API_SERVER < 500) >>> >>> /* use the same API call whose definition changed in 4.0.0 */ >>> >>> #else >>> #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x >>> #endif >>> >>> The other defines just make this a little cleaner looking: >>> >>> #if IPSEC_API_SERVER_MAJOR == 3 && IPSEC_API_SEMVER_MINOR >= 2 >>> >>> /* use an API introduced in ipsec.api verion 3.2.0 */ >>> >>> #elif IPSEC_API_SERVER_MAJOR == 4 >>> >>> /* use the same API call whose definition changed in 4.0.0 */ >>> >>> #else >>> #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x >>> #endif >>> >>> Thanks, >>> Chris. >>> On Feb 28, 2020, at 7:36 AM, otr...@employees.org wrote: Christian, > How does one conditionally compile code based on the API version? I was > looking for a compile time conditional I could then use #if's with, but I > can't seem to find one. A release version #define would work too, > although not be as nice as the per file semver one. > > I did find these are generated: > > #ifdef vl_api_version_tuple > vl_api_version_tuple(ipsec.api, 3, 0, 0) > #endif /* vl_api_version_tuple */ > > but I dont know how to utilize this during CPP in an #if conditional that functions is used like this: #define vl_api_version_tuple(n,mj, mi, p) \ vl_msg_api_add_version (am, #n, mj, mi, p); #include #undef vl_api_version_tuple But if you want a simple define to use I can trivially add something like: #define _SEMVER 1 Could go in .api_types.h Cheers, Ole >>> >> >> > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15626): https://lists.fd.io/g/vpp-dev/message/15626 Mute This Topic: https://lists.fd.io/mt/71604387/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] conditional compile based on API version?
> On Feb 28, 2020, at 11:49 AM, Ole Troan wrote: > > Christian, > > OK, can update to > #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ > > Just to be clear, > you don't use this on the VPP side, but on the client side right? Correct, it's for things like supporting VPP as an option in other open source projects like strongswan. > So if VAPI client wrapper provided this define, that would be fine too? I could include the vapi header to get to the define, sure. [ I don't actually use VAPI in my stuff b/c I don't want to have to define callbacks for every sync API function I use. :) ] Thanks, Chris. > > Cheers, > Ole > >> On 28 Feb 2020, at 16:56, Christian Hopps wrote: >> >> This would be great, but how about these defines get generated (e.g., for >> ipsec.api with version "3.2.1") >> >> #define IPSEC_API_SEMVER_MAJOR 3 >> #define IPSEC_API_SEMVER_MINOR 2 >> #define IPSEC_API_SEMVER_FIX 1 >> #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ >> >> The last define is all that's really needed though. >> >> Then one can do this in code: >> >> #if (IPSEC_API_SERVER < 400) && (IPSEC_API_SEMVER >= 3002000) >> >> /* use an API introduced in ipsec.api verion 3.2.0 */ >> >> #elif (IPSEC_API_SERVER >= 400) && (IPSEC_API_SERVER < 500) >> >> /* use the same API call whose definition changed in 4.0.0 */ >> >> #else >> #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x >> #endif >> >> The other defines just make this a little cleaner looking: >> >> #if IPSEC_API_SERVER_MAJOR == 3 && IPSEC_API_SEMVER_MINOR >= 2 >> >> /* use an API introduced in ipsec.api verion 3.2.0 */ >> >> #elif IPSEC_API_SERVER_MAJOR == 4 >> >> /* use the same API call whose definition changed in 4.0.0 */ >> >> #else >> #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x >> #endif >> >> Thanks, >> Chris. >> >>> On Feb 28, 2020, at 7:36 AM, otr...@employees.org wrote: >>> >>> Christian, >>> How does one conditionally compile code based on the API version? I was looking for a compile time conditional I could then use #if's with, but I can't seem to find one. A release version #define would work too, although not be as nice as the per file semver one. I did find these are generated: #ifdef vl_api_version_tuple vl_api_version_tuple(ipsec.api, 3, 0, 0) #endif /* vl_api_version_tuple */ but I dont know how to utilize this during CPP in an #if conditional >>> >>> that functions is used like this: >>> #define vl_api_version_tuple(n,mj, mi, p) \ >>> vl_msg_api_add_version (am, #n, mj, mi, p); >>> #include >>> #undef vl_api_version_tuple >>> >>> But if you want a simple define to use I can trivially add something like: >>> #define _SEMVER 1 >>> >>> Could go in .api_types.h >>> >>> Cheers, >>> Ole >> > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15625): https://lists.fd.io/g/vpp-dev/message/15625 Mute This Topic: https://lists.fd.io/mt/71604387/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] TLS configuration & throughput
Hi Florin, Thanks for the info. I pulled the latest and retried, things seem a bit better now from a stability perspective. The performance issue looks like a CPU limitation on the client side (10K loops/s) based on the results. I have these: *Client* : Intel Xeon CPU E5-2650 v2 @ 2.60GHz - 10210 loops/sec *Server* : Intel Xeon CPU E5-2640 v3 @ 2.60GHz - 1630780 loops/sec With these I'm getting 2.17 Gbps now. That's still a bit low, looking at the comparison between Xeon Gold 6146 and E5-2650 I can't really explain the 6x performance difference, but I have not really taken a dive into e.g. comparative AES NI performance etc. Thank you very much for all your input Florin, very much appreciated. *Client side stats:* Thread 1 vpp_wk_0 (lcore 22) Time 26.5, 10 sec internal node vector rate 12.94 loops/sec 10210.39 vector rates in 8.5489e4, out 7.5246e4, drop 5.6541e-1, punt 0.e0 *Server side stats:* Thread 1 vpp_wk_0 (lcore 22) Time 19.3, 10 sec internal node vector rate 4.79 loops/sec 1630780.69 vector rates in 1.1166e5, out 1.3379e4, drop 5.1882e-1, punt 0.e0 Regards, Dom -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15624): https://lists.fd.io/g/vpp-dev/message/15624 Mute This Topic: https://lists.fd.io/mt/71542617/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 configuration getting erased on VPP restart
Yes now its working. Thanks. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15623): https://lists.fd.io/g/vpp-dev/message/15623 Mute This Topic: https://lists.fd.io/mt/71609857/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] TLS configuration & throughput
Hi Dom, I guess you’re not using vpp master. Loops/s should appear in the line you highlighted Regards, Florin > On Feb 28, 2020, at 8:54 AM, dchons via Lists.Fd.Io > wrote: > > Hi Florin, > > I got another test run and was able to do the clear run; show run as you > suggested about 10 seconds into the test run just before it ended. I'm not > sure where to see the loops/s stat, so I've pasted the output from both > client and server below if you would not mind pointing out what I'm looking > for there. > > Thank you, > Dom > > Server side: > vpp# clear run > vpp# show run > Thread 0 vpp_main (lcore 20) > Time 91.1, 10 sec internal node vector rate 0.00 > vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0 > Name State Calls Vectors > Suspends Clocks Vectors/Call > api-rx-from-ringany wait 0 0 > 23 5.63e50.00 > dpdk-processany wait 0 0 > 31 2.25e50.00 > fib-walkany wait 0 0 > 46 2.41e30.00 > ikev2-manager-process any wait 0 0 > 92 1.78e30.00 > ip4-full-reassembly-expire-wal any wait 0 0 >9 2.48e30.00 > ip4-sv-reassembly-expire-walk any wait 0 0 >9 1.85e30.00 > ip6-full-reassembly-expire-wal any wait 0 0 >9 2.13e30.00 > ip6-mld-process any wait 0 0 > 92 1.20e30.00 > ip6-ra-process any wait 0 0 > 92 1.42e30.00 > ip6-sv-reassembly-expire-walk any wait 0 0 >9 2.19e30.00 > session-queue-process any wait 0 0 > 92 2.76e30.00 > statseg-collector-process time wait0 0 >9 1.95e40.00 > unix-cli-stdin active 0 0 >9 1.08e50.00 > unix-epoll-input polling 1435898 0 >0 1.64e50.00 > --- > Thread 1 vpp_wk_0 (lcore 22) > Time 91.1, 10 sec internal node vector rate 4.57 > vector rates in 3.0737e4, out 3.8315e3, drop 5.5956e-1, punt 0.e0 > Name State Calls Vectors > Suspends Clocks Vectors/Call > TenGigabitEthernet5/0/0-output active 349212 349212 >0 5.12e21.00 > TenGigabitEthernet5/0/0-tx active 349212 349212 >0 7.47e21.00 > arp-inputactive 1 1 >0 3.55e31.00 > arp-replyactive 1 1 >0 3.50e41.00 > dpdk-input polling 372763251 2452218 >0 2.77e40.00 > drop active 51 51 >0 9.22e21.00 > error-drop active 51 51 >0 7.54e21.00 > ethernet-input active 349264 2452218 >0 1.32e27.02 > interface-output active 1 1 >0 8.01e31.00 > ip4-drop active 3 3 >0 2.86e31.00 > ip4-input-no-checksumactive 349218 2452169 >0 1.26e27.02 > ip4-localactive 349218 2452169 >0 4.12e27.02 > ip4-lookup active 454319 2801380 >0 1.33e26.17 > ip4-rewrite active 349211 349211 >0 4.97e21.00 > llc-inputactive 45 45 >0 7.17e21.00 > lldp-input active 3 3 >0
Re: [vpp-dev] VPP configuration getting erased on VPP restart
Hi Chinmaya.
Follow Dave's input.
I'm obsessive over typo's/transcription errors, so I've done it like this
in the past:
Edit your startup.conf to include:
unix {
nodaemon
*log /etc/vpp/startup-conf*
full-coredump
cli-listen /run/vpp/cli.sock
gid vpp
}
start vpp and configure your systemas you like.
stop vpp (systemctl stop vpp)
edit /etc/vpp/startup-conf to remove the timestamps and place each command
on a new line.
then edit startup.conf to replace the 'log' keyword with 'startup-config'
to look like:
unix {
nodaemon
*startup-config /etc/vpp/startup-conf*
full-coredump
cli-listen /run/vpp/cli.sock
gid vpp
}
and restart vpp (systemctl restart vpp)
On Fri, Feb 28, 2020 at 11:35 AM Dave Barach via Lists.Fd.Io wrote:
> Please do exactly what I suggested. Here’s why: restarting vpp via “vppctl
> restart” re-executes vpp with *precisely* the same command line arguments
> passed to it e.g. via systemctl.
>
>
>
> Until you start vpp with the command line argument change I told you
> about, there’s no chance you’ll get the effect you’re looking for. None.
> Zero. Zip. Nada.
>
>
>
> *From:* vpp-dev@lists.fd.io *On Behalf Of *Chinmaya
> Aggarwal
> *Sent:* Friday, February 28, 2020 11:23 AM
> *To:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] VPP configuration getting erased on VPP restart
>
>
>
> I did restart vpp using "vppctl restart" but I couldn't find the
> configuration. When i reboot the machine then only i could see my
> configuration. I am running VPP version 19.08. What could be the reason for
> this?
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15621): https://lists.fd.io/g/vpp-dev/message/15621
Mute This Topic: https://lists.fd.io/mt/71609857/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] TLS configuration & throughput
Hi Florin, I got another test run and was able to do the clear run; show run as you suggested about 10 seconds into the test run just before it ended. I'm not sure where to see the loops/s stat, so I've pasted the output from both client and server below if you would not mind pointing out what I'm looking for there. Thank you, Dom *Server side:* vpp# clear run vpp# show run Thread 0 vpp_main (lcore 20) Time 91.1, 10 sec internal node vector rate 0.00 vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0 Name State Calls Vectors Suspends Clocks Vectors/Call api-rx-from-ring any wait 0 0 23 5.63e5 0.00 dpdk-process any wait 0 0 31 2.25e5 0.00 fib-walk any wait 0 0 46 2.41e3 0.00 ikev2-manager-process any wait 0 0 92 1.78e3 0.00 ip4-full-reassembly-expire-wal any wait 0 0 9 2.48e3 0.00 ip4-sv-reassembly-expire-walk any wait 0 0 9 1.85e3 0.00 ip6-full-reassembly-expire-wal any wait 0 0 9 2.13e3 0.00 ip6-mld-process any wait 0 0 92 1.20e3 0.00 ip6-ra-process any wait 0 0 92 1.42e3 0.00 ip6-sv-reassembly-expire-walk any wait 0 0 9 2.19e3 0.00 session-queue-process any wait 0 0 92 2.76e3 0.00 statseg-collector-process time wait 0 0 9 1.95e4 0.00 unix-cli-stdin active 0 0 9 1.08e5 0.00 unix-epoll-input polling 1435898 0 0 1.64e5 0.00 --- Thread 1 vpp_wk_0 (lcore 22) Time 91.1, 10 sec internal node vector rate 4.57 vector rates in 3.0737e4, out 3.8315e3, drop 5.5956e-1, punt 0.e0 Name State Calls Vectors Suspends Clocks Vectors/Call TenGigabitEthernet5/0/0-output active 349212 349212 0 5.12e2 1.00 TenGigabitEthernet5/0/0-tx active 349212 349212 0 7.47e2 1.00 arp-input active 1 1 0 3.55e3 1.00 arp-reply active 1 1 0 3.50e4 1.00 dpdk-input polling 372763251 2452218 0 2.77e4 0.00 drop active 51 51 0 9.22e2 1.00 error-drop active 51 51 0 7.54e2 1.00 ethernet-input active 349264 2452218 0 1.32e2 7.02 interface-output active 1 1 0 8.01e3 1.00 ip4-drop active 3 3 0 2.86e3 1.00 ip4-input-no-checksum active 349218 2452169 0 1.26e2 7.02 ip4-local active 349218 2452169 0 4.12e2 7.02 ip4-lookup active 454319 2801380 0 1.33e2 6.17 ip4-rewrite active 349211 349211 0 4.97e2 1.00 llc-input active 45 45 0 7.17e2 1.00 lldp-input active 3 3 0 2.73e3 1.00 session-queue polling 372763251 349209 0 2.94e5 0.00 tcp4-established active 349211 2452161 0 4.53e3 7.02 tcp4-input active 349215 2452166 0 2.23e2
Re: [vpp-dev] conditional compile based on API version?
Christian, OK, can update to #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ Just to be clear, you don't use this on the VPP side, but on the client side right? So if VAPI client wrapper provided this define, that would be fine too? Cheers, Ole > On 28 Feb 2020, at 16:56, Christian Hopps wrote: > > This would be great, but how about these defines get generated (e.g., for > ipsec.api with version "3.2.1") > > #define IPSEC_API_SEMVER_MAJOR 3 > #define IPSEC_API_SEMVER_MINOR 2 > #define IPSEC_API_SEMVER_FIX 1 > #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ > > The last define is all that's really needed though. > > Then one can do this in code: > > #if (IPSEC_API_SERVER < 400) && (IPSEC_API_SEMVER >= 3002000) > >/* use an API introduced in ipsec.api verion 3.2.0 */ > > #elif (IPSEC_API_SERVER >= 400) && (IPSEC_API_SERVER < 500) > >/* use the same API call whose definition changed in 4.0.0 */ > > #else > #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x > #endif > > The other defines just make this a little cleaner looking: > > #if IPSEC_API_SERVER_MAJOR == 3 && IPSEC_API_SEMVER_MINOR >= 2 > >/* use an API introduced in ipsec.api verion 3.2.0 */ > > #elif IPSEC_API_SERVER_MAJOR == 4 > >/* use the same API call whose definition changed in 4.0.0 */ > > #else > #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x > #endif > > Thanks, > Chris. > >> On Feb 28, 2020, at 7:36 AM, otr...@employees.org wrote: >> >> Christian, >> >>> How does one conditionally compile code based on the API version? I was >>> looking for a compile time conditional I could then use #if's with, but I >>> can't seem to find one. A release version #define would work too, although >>> not be as nice as the per file semver one. >>> >>> I did find these are generated: >>> >>> #ifdef vl_api_version_tuple >>> vl_api_version_tuple(ipsec.api, 3, 0, 0) >>> #endif /* vl_api_version_tuple */ >>> >>> but I dont know how to utilize this during CPP in an #if conditional >> >> that functions is used like this: >> #define vl_api_version_tuple(n,mj, mi, p) \ >> vl_msg_api_add_version (am, #n, mj, mi, p); >> #include >> #undef vl_api_version_tuple >> >> But if you want a simple define to use I can trivially add something like: >> #define _SEMVER 1 >> >> Could go in .api_types.h >> >> Cheers, >> Ole > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15619): https://lists.fd.io/g/vpp-dev/message/15619 Mute This Topic: https://lists.fd.io/mt/71604387/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 configuration getting erased on VPP restart
Please do exactly what I suggested. Here’s why: restarting vpp via “vppctl restart” re-executes vpp with precisely the same command line arguments passed to it e.g. via systemctl. Until you start vpp with the command line argument change I told you about, there’s no chance you’ll get the effect you’re looking for. None. Zero. Zip. Nada. From: vpp-dev@lists.fd.io On Behalf Of Chinmaya Aggarwal Sent: Friday, February 28, 2020 11:23 AM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VPP configuration getting erased on VPP restart I did restart vpp using "vppctl restart" but I couldn't find the configuration. When i reboot the machine then only i could see my configuration. I am running VPP version 19.08. What could be the reason for this? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15618): https://lists.fd.io/g/vpp-dev/message/15618 Mute This Topic: https://lists.fd.io/mt/71609857/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 configuration getting erased on VPP restart
I did restart vpp using "vppctl restart" but I couldn't find the configuration. When i reboot the machine then only i could see my configuration. I am running VPP version 19.08. What could be the reason for this? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15617): https://lists.fd.io/g/vpp-dev/message/15617 Mute This Topic: https://lists.fd.io/mt/71609857/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 configuration getting erased on VPP restart
Simply restart the vpp service: “service vpp restart” on Ubuntu, etc. From: vpp-dev@lists.fd.io On Behalf Of Chinmaya Aggarwal Sent: Friday, February 28, 2020 11:00 AM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VPP configuration getting erased on VPP restart I found this solution but it works only if I do this change and reboot the machine. Is there any way by which i don't need to reboot the machine and the configuration get persist right after modifying startup.conf? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15616): https://lists.fd.io/g/vpp-dev/message/15616 Mute This Topic: https://lists.fd.io/mt/71609857/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 configuration getting erased on VPP restart
I found this solution but it works only if I do this change and reboot the machine. Is there any way by which i don't need to reboot the machine and the configuration get persist right after modifying startup.conf? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15615): https://lists.fd.io/g/vpp-dev/message/15615 Mute This Topic: https://lists.fd.io/mt/71609857/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] conditional compile based on API version?
This would be great, but how about these defines get generated (e.g., for ipsec.api with version "3.2.1") #define IPSEC_API_SEMVER_MAJOR 3 #define IPSEC_API_SEMVER_MINOR 2 #define IPSEC_API_SEMVER_FIX 1 #define IPSEC_API_SEMVER 3002001 /* MMMmmmppp */ The last define is all that's really needed though. Then one can do this in code: #if (IPSEC_API_SERVER < 400) && (IPSEC_API_SEMVER >= 3002000) /* use an API introduced in ipsec.api verion 3.2.0 */ #elif (IPSEC_API_SERVER >= 400) && (IPSEC_API_SERVER < 500) /* use the same API call whose definition changed in 4.0.0 */ #else #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x #endif The other defines just make this a little cleaner looking: #if IPSEC_API_SERVER_MAJOR == 3 && IPSEC_API_SEMVER_MINOR >= 2 /* use an API introduced in ipsec.api verion 3.2.0 */ #elif IPSEC_API_SERVER_MAJOR == 4 /* use the same API call whose definition changed in 4.0.0 */ #else #error code only supports VPP ipsec.api between 3.2.0 and 4.x.x #endif Thanks, Chris. > On Feb 28, 2020, at 7:36 AM, otr...@employees.org wrote: > > Christian, > >> How does one conditionally compile code based on the API version? I was >> looking for a compile time conditional I could then use #if's with, but I >> can't seem to find one. A release version #define would work too, although >> not be as nice as the per file semver one. >> >> I did find these are generated: >> >> #ifdef vl_api_version_tuple >> vl_api_version_tuple(ipsec.api, 3, 0, 0) >> #endif /* vl_api_version_tuple */ >> >> but I dont know how to utilize this during CPP in an #if conditional > > that functions is used like this: > #define vl_api_version_tuple(n,mj, mi, p) \ > vl_msg_api_add_version (am, #n, mj, mi, p); > #include > #undef vl_api_version_tuple > > But if you want a simple define to use I can trivially add something like: > #define _SEMVER 1 > > Could go in .api_types.h > > Cheers, > Ole -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15614): https://lists.fd.io/g/vpp-dev/message/15614 Mute This Topic: https://lists.fd.io/mt/71604387/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 configuration getting erased on VPP restart
By itself vpp is a pure data plane which does not store persistent
configuration.
However, if you place your startup configuration in
“/wherever/my_startup_config” and edit /etc/vpp/startup.conf as shown, you’ll
get the effect that you want.
unix {
nodaemon
log /var/log/vpp/vpp.log
full-coredump
cli-listen /run/vpp/cli.sock
startup-config /wherever/my_startup_config
gid vpp
}
HTH... Dave
From: vpp-dev@lists.fd.io On Behalf Of Chinmaya Aggarwal
Sent: Friday, February 28, 2020 10:04 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP configuration getting erased on VPP restart
Hi,
I ran a few commands on VPP. But, when i restarted the vpp, I can't see the
configuration anymore. Can you please suggest how can I persist my entered
configuration on vpp restart?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15613): https://lists.fd.io/g/vpp-dev/message/15613
Mute This Topic: https://lists.fd.io/mt/71609857/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] VPP configuration getting erased on VPP restart
Hi, I ran a few commands on VPP. But, when i restarted the vpp, I can't see the configuration anymore. Can you please suggest how can I persist my entered configuration on vpp restart? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15612): https://lists.fd.io/g/vpp-dev/message/15612 Mute This Topic: https://lists.fd.io/mt/71609857/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] Can I submit some API changes for 19.08, et al. release branches?
Hi Chris,
There are two overlapping sets of paths associated with each prefix in the FIB;
the desired set as programmed by the control plane and the set that can be used
(based on path availability, based on e.g. link or BFD state). I assume you
fetch the former by parsing through the path-list – is that what you were
looking for? The latter is subject to change without notice to the client.
/neale
From: on behalf of Christian Hopps
Date: Tuesday 25 February 2020 at 22:09
To: Andrew Yourtchenko
Cc: Christian Hopps , "Dave Barach (dbarach)"
, vpp-dev
Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release
branches?
> On Feb 25, 2020, at 3:44 PM, Andrew Yourtchenko wrote:
>
> That’s the APIs in the master prior to the API freeze, in my book.
>
> The today’s situation is:
>
> - want bleeding edge features ? Use master.
> - want sort-of-boring-stability ? Use release branch
>
> Now, I am really interested why the folks who do want to experiment with the
> APIs, do not pick the master ? (Say, specifically for your case).
FWIW, I'm absolutely fine following whatever guidelines, it's open source and
I'm sure people can make things work with whatever is best for both project[s].
In my case we're not really talking about an API that is "bleeding edge", but
rather "waited around for someone to need/implement it". Doing a route/fib
entry lookup isn't very bleeding edge given what VPP does. :)
My use case is interfacing an external IKE daemon (strongswan), I want to do a
route lookup (rather than download the entire FIB content and search for a
match myself hoping to use the same criteria that VPP would, which is the only
current API solution available).
I'd like to contribute my strongswan changes back to strongswan project, but
having them only be usable for some future yet-to-be-released version of VPP
might not be useful to people shipping products based mostly on
"sort-of-boring-but-stable" features.
Also worth noting, I implemented a basic route lookup (prefix based, from a
given table, either exact or longest prefix match), I didn't add any other
filtering or fanciness. I figured fanciness could be added later (if needed),
and went for simple, and if more complexity was needed, well there's always
what came before it. :)
define ip_route_lookup
{
u32 client_index;
u32 context;
u32 table_id;
u8 exact;
vl_api_prefix_t prefix;
};
define ip_route_lookup_reply
{
u32 context;
i32 retval;
vl_api_ip_route_t route;
};
Thanks,
Chris.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15611): https://lists.fd.io/g/vpp-dev/message/15611
Mute This Topic: https://lists.fd.io/mt/71535081/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] Can I submit some API changes for 19.08, et al. release branches?
Hi Chris, > > In my opinion it would be contrary to the design philosophy. > > My reasoning is this. VPP is a forwarder, it's place in the network stack is the SW ASIC equivalent. Ok. That's interesting. In the end this is about building things right? Sure. My mantra is often that functionality can often best be added through layering and composition rather than building one app to rule them all. Here's my $.02: - VPP provides packet processing as part of this it: - Provides a FIB. - Owns and provides interfaces which have addresses - Moves packets between interfaces based on the FIB. - It does a ton of other really non-ASICy stuff too but let's keep it simple - A good interface for managing the above resources allows multiple non-conflicting clients. - Multiple clients should not have to have a full-mesh of connectivity and knowledge of each others state to infer the state that exists inside VPP. Perhaps I misunderstand, but it seems to me that full mesh connectivity is what you are after, with VPP providing the mesh. i.e. all clients can send state to all other clients via VPP. For example, most entities in a control plane need to know which interfaces exist. A good example of an API for the above is rtnetlink http://man7.org/linux/man-pages/man7/rtnetlink.7.html BSD has one as well https://www.freebsd.org/cgi/man.cgi?query=route=4=netbsd Right, netlink is a means for clients to broadcast/multicast state to all other clients that are interested - this is what I mean when I say 'message bus' These APIs (to the same resources VPP provides -- FIB and Interfaces) work well and allow for multiple applications that do different things all to be written easily and be plugged together. This would not be possible if all those applications had to have intimate knowledge and communicate between of each other. Right, they communicate using the common data representation and tx/rx semantics of the message bus. It's just a good design. I would call this an API to a shared resource. Calling it a message bus feels more like the seed for an April 1st RFC. I don't think it helps get a good API built to focus on how it could be misused. Just because one *could* use an API to a shared resource to exchange information (odd as that would be to do) doesn't mean that the API is broken, it just means someone would be misusing it. I think we are disagreeing on two points; 1) the definition of 'the API'. For me the VPP API is the means by which clients program VPP. If I understand you correctly the API is a means to disseminate information to various entities in the system. I claim one should layer the latter on the former. 2) VPP as a shared resource. VPP is not the source of truth. Generally, If A programmes B with state X then A is still the source of truth for X, it doesn't transfer to B. So if a client wants to know, e.g. the IP addresses applied to each interface, it is best to query the interface-manager. Again, my opinion is but one of many, and I feel like I'm starting to sound like a stuck record __ so I'll lay low for a while and keep the airways open. /neale Thanks, Chris. > It's primary goal is thus to forward packets as fast as possible, it's secondary goal is to be programmable as fast as possible (particularly for routes, of which there can be millions). Any other functions that might be expected of VPP that run against these objectives are not 'allowed'. Being a messages bus, netlink broadcaster etc is against its second objective - we don't want to spend cycles broadcasting/multicasting notifications from client x to a set of clients y through a set of filters z. > > Of course that's not to say one can't build a multicasting layer on top of VPP, in a separate process, that performs these functions. > > Please also note: > https://wiki.fd.io/view/VPP/RM > when considering using multiple clients with VPP. > > Naturally, my opinion is but one of many... > > /neale > > > On 27/02/2020 17:56, "Christian Hopps" wrote: > > > >> On Feb 27, 2020, at 11:45 AM, Neale Ranns (nranns) wrote: >> >> >> Hi Chris, >> >> There is a design philosophy against sending notifications to agents about information that comes from agents. This is in contrast to notifications to agents about events that occur in the data-plane, like DHCP lease, new ARP/ND, learned L2 addresses, etc. > >That doesn't really help me understand and worries me more. > >Would providing the same functionality as exists in the netlink socket (for routes and interfaces) be against VPP design philosophy? > >Thanks, >Chris. > > > >> >> /neale >> >> From: on behalf of
[vpp-dev] Coverity run FAILED as of 2020-02-28 14:00:24 UTC
Coverity run failed today. Current number of outstanding issues are 6 Newly detected: 0 Eliminated: 0 More details can be found at https://scan.coverity.com/projects/fd-io-vpp/view_defects -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15609): https://lists.fd.io/g/vpp-dev/message/15609 Mute This Topic: https://lists.fd.io/mt/71608599/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] conditional compile based on API version?
Christian, Check if you are happy with: https://gerrit.fd.io/r/c/vpp/+/25540 vppapigen: generate define for module_semver Cheers, Ole > On 28 Feb 2020, at 09:09, Christian Hopps wrote: > > How does one conditionally compile code based on the API version? I was > looking for a compile time conditional I could then use #if's with, but I > can't seem to find one. A release version #define would work too, although > not be as nice as the per file semver one. > > I did find these are generated: > > #ifdef vl_api_version_tuple > vl_api_version_tuple(ipsec.api, 3, 0, 0) > #endif /* vl_api_version_tuple */ > > but I dont know how to utilize this during CPP in an #if conditional > > Thanks, > Chris. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15608): https://lists.fd.io/g/vpp-dev/message/15608 Mute This Topic: https://lists.fd.io/mt/71604387/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] conditional compile based on API version?
Christian, > How does one conditionally compile code based on the API version? I was > looking for a compile time conditional I could then use #if's with, but I > can't seem to find one. A release version #define would work too, although > not be as nice as the per file semver one. > > I did find these are generated: > > #ifdef vl_api_version_tuple > vl_api_version_tuple(ipsec.api, 3, 0, 0) > #endif /* vl_api_version_tuple */ > > but I dont know how to utilize this during CPP in an #if conditional that functions is used like this: #define vl_api_version_tuple(n,mj, mi, p) \ vl_msg_api_add_version (am, #n, mj, mi, p); #include #undef vl_api_version_tuple But if you want a simple define to use I can trivially add something like: #define _SEMVER 1 Could go in .api_types.h Cheers, Ole-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15607): https://lists.fd.io/g/vpp-dev/message/15607 Mute This Topic: https://lists.fd.io/mt/71604387/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] Q: how best to avoid locking for cleanup.
On 2/28/20, Honnappa Nagarahalli wrote:
>> On the other hand, if you do modify shared data structures in the
>> datapath,
>> you are on your own - you need to take care of the data consistency.
>> Again, the way we usually deal with that is to do a "rpc" to the main
>> thread -
>> then the main thread can request the worker barrier, etc.
>>
>> Or do you refer to other situations?
> I was looking at the bi-hash library on a standalone basis. The entries are
> deleted and buckets are freed without any synchronization between the writer
FWIW, the above statement is incorrect if all we are talking is pure
bihash operation with values that are not used as keys for subsequent
memory accesses in other data structures. This code in
include/vppinfra/bihash_template.c might be of interest:
static inline int BV (clib_bihash_add_del_inline)
(BVT (clib_bihash) * h, BVT (clib_bihash_kv) * add_v, int is_add,
int (*is_stale_cb) (BVT (clib_bihash_kv) *, void *), void *arg)
{
u32 bucket_index;
...
BV (clib_bihash_lock_bucket) (b); <- LOCK
/* First elt in the bucket? */
if (BV (clib_bihash_bucket_is_empty) (b))
{
if (is_add == 0)
{
BV (clib_bihash_unlock_bucket) (b);
return (-1);
}
/* Move readers to a (locked) temp copy of the bucket */
BV (clib_bihash_alloc_lock) (h);<- LOCK
BV (make_working_copy) (h, b);
-
and so on.
when performing the actual bihash operations as a user of the bihash,
you most definitely do *not* need any extra locking, the bihash is
doing it for you behind the scenes.
There is only one transient condition that I had seen - under intense
add/delete workload, the readers in other threads may see the lookup
successful but the value returned being ~0.
That is fairly easy to deal with.
But of course there is a race in case you are using bihash to store
secondary indices into your own data structures - if you are deleting
a bihash entry, another thread may have *just* made a lookup, obtained
the index, and is using that index, so for that part you do need to
take care of by yourself, indeed.
--a
> and the data plane threads. If the synchronization is handled outside of
> this library using 'worker barrier' it should be alright.
>
>>
>> Best
>> Ben
>>
>> > -Original Message-
>> > From: vpp-dev@lists.fd.io On Behalf Of Honnappa
>> > Nagarahalli
>> > Sent: jeudi 27 février 2020 17:51
>> > To: cho...@chopps.org; vpp-dev@lists.fd.io; Honnappa Nagarahalli
>> >
>> > Cc: nd
>> > Subject: Re: [vpp-dev] Q: how best to avoid locking for cleanup.
>> >
>> > I think there are similar issues in bi-hash (i.e. the entry could be
>> > deleted from control plane while the data plane threads are doing the
>> > lookup).
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Honnappa
>> >
>> >
>> >
>> > From: vpp-dev@lists.fd.io On Behalf Of Christian
>> > Hopps via Lists.Fd.Io
>> > Sent: Thursday, February 27, 2020 5:09 AM
>> > To: vpp-dev
>> > Cc: vpp-dev@lists.fd.io
>> > Subject: Re: [vpp-dev] Q: how best to avoid locking for cleanup.
>> >
>> >
>> >
>> > I received a private message indicating that one solution was to just
>> > wait "long enough" for the packets to drain. This is the method I'm
>> > going to go with as it's simple (albeit not as deterministic as some
>> > marking/callback scheme :)
>> >
>> > For my case I think I can wait ridiculously long for "long enough" and
>> > just have a process do garbage collection after a full second.
>> >
>> > I do wonder how many other cases of "state associated with in-flight
>> > packets" there might be, and if more sophisticated general solution
>> > might be useful.
>> >
>> > Thanks,
>> > Chris.
>> >
>> > > On Feb 25, 2020, at 6:27 PM, Christian Hopps > > > wrote:
>> > >
>> > > I've got a (hopefully) interesting problem with locking in VPP.
>> > >
>> > > I need to add some cleanup code to my IPTFS additions to ipsec.
>> > Basically I have some per-SA queues that I need to cleanup when an SA
>> > is deleted.
>> > >
>> > > - ipsec only deletes it's SAs when its "fib_node" locks reach zero.
>> > > - I hoping this means that ipsec will only be deleting the SA after
>> > > the
>> > FIB has stopped injecting packets "along" this SA path (i.e., it's
>> > removed prior to the final unlock/deref).
>> > > - I'm being called back by ipsec during the SA deletion.
>> > > - I have queues (one RX for reordering, one TX for aggregation and
>> > subsequent output) associated with the SA, both containing locks, that
>> > need to be emptied and freed.
>> > > - These queues are being used in multiple worker threads in various
>> > graph nodes in parallel.
>> > >
>> > > What I think this means is that when my "SA deleted" callback is
>> > > called,
>> > no *new* packets will be delivered on the SA path. Good so far.
>> > >
>> > > What I'm concerned with is the packets that may currently be
>> > > "in-flight"
>> > in the graph, as these will have
Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches?
> On Feb 28, 2020, at 5:06 AM, Neale Ranns (nranns) wrote: > > > Hi Chris, > > In my opinion it would be contrary to the design philosophy. > > My reasoning is this. VPP is a forwarder, it's place in the network stack is > the SW ASIC equivalent. Ok. That's interesting. In the end this is about building things right? Here's my $.02: - VPP provides packet processing as part of this it: - Provides a FIB. - Owns and provides interfaces which have addresses - Moves packets between interfaces based on the FIB. - It does a ton of other really non-ASICy stuff too but let's keep it simple - A good interface for managing the above resources allows multiple non-conflicting clients. - Multiple clients should not have to have a full-mesh of connectivity and knowledge of each others state to infer the state that exists inside VPP. A good example of an API for the above is rtnetlink http://man7.org/linux/man-pages/man7/rtnetlink.7.html BSD has one as well https://www.freebsd.org/cgi/man.cgi?query=route=4=netbsd These APIs (to the same resources VPP provides -- FIB and Interfaces) work well and allow for multiple applications that do different things all to be written easily and be plugged together. This would not be possible if all those applications had to have intimate knowledge and communicate between of each other. It's just a good design. I would call this an API to a shared resource. Calling it a message bus feels more like the seed for an April 1st RFC. I don't think it helps get a good API built to focus on how it could be misused. Just because one *could* use an API to a shared resource to exchange information (odd as that would be to do) doesn't mean that the API is broken, it just means someone would be misusing it. Thanks, Chris. > It's primary goal is thus to forward packets as fast as possible, it's > secondary goal is to be programmable as fast as possible (particularly for > routes, of which there can be millions). Any other functions that might be > expected of VPP that run against these objectives are not 'allowed'. Being a > messages bus, netlink broadcaster etc is against its second objective - we > don't want to spend cycles broadcasting/multicasting notifications from > client x to a set of clients y through a set of filters z. > > Of course that's not to say one can't build a multicasting layer on top of > VPP, in a separate process, that performs these functions. > > Please also note: > https://wiki.fd.io/view/VPP/RM > when considering using multiple clients with VPP. > > Naturally, my opinion is but one of many... > > /neale > > > On 27/02/2020 17:56, "Christian Hopps" wrote: > > > >> On Feb 27, 2020, at 11:45 AM, Neale Ranns (nranns) wrote: >> >> >> Hi Chris, >> >> There is a design philosophy against sending notifications to agents about >> information that comes from agents. This is in contrast to notifications to >> agents about events that occur in the data-plane, like DHCP lease, new >> ARP/ND, learned L2 addresses, etc. > >That doesn't really help me understand and worries me more. > >Would providing the same functionality as exists in the netlink socket > (for routes and interfaces) be against VPP design philosophy? > >Thanks, >Chris. > > > >> >> /neale >> >> From: on behalf of Christian Hopps >> Date: Thursday 27 February 2020 at 16:32 >> To: "Neale Ranns (nranns)" >> Cc: Christian Hopps , "vpp-dev@lists.fd.io" >> >> Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. >> release branches? >> >> >> >>> On Feb 27, 2020, at 9:41 AM, Neale Ranns via Lists.Fd.Io >>> wrote: >>> >>> >>> >>> From: on behalf of Christian Hopps >>> Date: Thursday 27 February 2020 at 15:16 >>> To: "Neale Ranns (nranns)" >>> Cc: Christian Hopps , Andrew Yourtchenko >>> , "Dave Barach (dbarach)" , vpp-dev >>> >>> Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. >>> release branches? >>> >>> [snip] In my case we're not really talking about an API that is "bleeding edge", but rather "waited around for someone to need/implement it". Doing a route/fib entry lookup isn't very bleeding edge given what VPP does. :) True but the general usage model for VPP is that there is one agent/client giving it all the state it needs to function. So why would that agent need lookup functions, it has all the data already. The dump APIs serve to repopulate the agent with all state should it crash. >>> >>> I suppose that's why I needed to add this API then. :) >>> >>> We're using VPP more like a replacement for the kernel networking stack, >>> with multiple networking clients interfacing to it, rather than just one >>> monolithic application. >>> >>> Ok. Just don’t fall into the pit that is ‘I want VPP to tell client X when >>> client Y does something’ – VPP is not a message bus >> >> I'd like to be careful here. If
Re: [vpp-dev] conditional compile based on API version?
Hi Chris, yeah it is a bit of a tricky thing to do with the CPP. But doable, here is one option: #include "custom-codegen.h" /* https://gist.github.com/ayourtch/b56bf28a05db07878e4951c6c2539754 */ #define IPSEC_3_0 #define EA(a, b) this is empty action for codegen for a and b (when the API is the expected version) #define NEA(a, b) this is non-empty action codegen for a and b (when the API is not the expected version) #define vl_api_version_tuple(api, x, y, z) CCG_TEST_EMPTY_CB2(IPSEC_ ## x ## _ ## y, EA, NEA, itsA, itsB) /* this comes from ipsec.api.h contents, * we can see two examples - when the api there is defined * as is the expected version and when it isn't... * so the below lines correspond to a single #include line on two different API versions */ vl_api_version_tuple(ipsec.api, 1, 0, 0) vl_api_version_tuple(ipsec.api, 3, 0, 0) #undef IPSEC_3_0 #undef EA #undef NEA #undef vl_api_version_tuple the above snippet checks if the macro parametrized by the API version numbers if defined, and if it is, it expands one parametrized macro using the arguments you supply, and if it isn't - then it expands the other macro (which in your case would be an empty string, or some other fallback functionality). Not extremely pretty, but does the trick. I think these macros can be tweaked to do multi-check (I have in the very same gist another set of macros that does approximately that), but you get the idea :) cpp actually does have a little ugly duckling of a functional language hiding underneath it all... :-) --a On 2/28/20, Christian Hopps wrote: > How does one conditionally compile code based on the API version? I was > looking for a compile time conditional I could then use #if's with, but I > can't seem to find one. A release version #define would work too, although > not be as nice as the per file semver one. > > I did find these are generated: > > #ifdef vl_api_version_tuple > vl_api_version_tuple(ipsec.api, 3, 0, 0) > #endif /* vl_api_version_tuple */ > > but I dont know how to utilize this during CPP in an #if conditional > > Thanks, > Chris. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15604): https://lists.fd.io/g/vpp-dev/message/15604 Mute This Topic: https://lists.fd.io/mt/71604387/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] Can I submit some API changes for 19.08, et al. release branches?
Hi Chris, In my opinion it would be contrary to the design philosophy. My reasoning is this. VPP is a forwarder, it's place in the network stack is the SW ASIC equivalent. It's primary goal is thus to forward packets as fast as possible, it's secondary goal is to be programmable as fast as possible (particularly for routes, of which there can be millions). Any other functions that might be expected of VPP that run against these objectives are not 'allowed'. Being a messages bus, netlink broadcaster etc is against its second objective - we don't want to spend cycles broadcasting/multicasting notifications from client x to a set of clients y through a set of filters z. Of course that's not to say one can't build a multicasting layer on top of VPP, in a separate process, that performs these functions. Please also note: https://wiki.fd.io/view/VPP/RM when considering using multiple clients with VPP. Naturally, my opinion is but one of many... /neale On 27/02/2020 17:56, "Christian Hopps" wrote: > On Feb 27, 2020, at 11:45 AM, Neale Ranns (nranns) wrote: > > > Hi Chris, > > There is a design philosophy against sending notifications to agents about information that comes from agents. This is in contrast to notifications to agents about events that occur in the data-plane, like DHCP lease, new ARP/ND, learned L2 addresses, etc. That doesn't really help me understand and worries me more. Would providing the same functionality as exists in the netlink socket (for routes and interfaces) be against VPP design philosophy? Thanks, Chris. > > /neale > > From: on behalf of Christian Hopps > Date: Thursday 27 February 2020 at 16:32 > To: "Neale Ranns (nranns)" > Cc: Christian Hopps , "vpp-dev@lists.fd.io" > Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches? > > > > > On Feb 27, 2020, at 9:41 AM, Neale Ranns via Lists.Fd.Io wrote: > > > > > > > > From: on behalf of Christian Hopps > > Date: Thursday 27 February 2020 at 15:16 > > To: "Neale Ranns (nranns)" > > Cc: Christian Hopps , Andrew Yourtchenko , "Dave Barach (dbarach)" , vpp-dev > > Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches? > > > > [snip] > > > > > > In my case we're not really talking about an API that is "bleeding edge", but rather "waited around for someone to need/implement it". Doing a route/fib entry lookup isn't very bleeding edge given what VPP does. :) > > > > > > True but the general usage model for VPP is that there is one agent/client giving it all the state it needs to function. So why would that agent need lookup functions, it has all the data already. The dump APIs serve to repopulate the agent with all state should it crash. > > > > I suppose that's why I needed to add this API then. :) > > > > We're using VPP more like a replacement for the kernel networking stack, with multiple networking clients interfacing to it, rather than just one monolithic application. > > > > Ok. Just don’t fall into the pit that is ‘I want VPP to tell client X when client Y does something’ – VPP is not a message bus > > I'd like to be careful here. If VPP is serving as a replacement for the networking stack with multiple clients interfacing to it, then it does serve as the single-source-of-truth on things like interface state, routes, etc. So, I do want to hear inside my IKE daemon from VPP that a route, intefrace, etc, may have changed, I don't want to have to interface the IKE daemon to N possible pieces of software that might modify routes, interfaces, etc. > > I'm only being careful here b/c if one looks at e.g., netlink functionality and then at the VPP api there are some gaps (e.g., interface address add/del and route add delete events are missing I believe). I'm assuming that these gaps exist b/c, as you say, people have generally not needed them, but not b/c there a design philosophy against them. > > Thanks, > Chris. > > > > > /neale > > > > > > Thanks, > > Chris. > > > > > > > > /neale > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15603): https://lists.fd.io/g/vpp-dev/message/15603 Mute This Topic: https://lists.fd.io/mt/71535081/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] conditional compile based on API version?
How does one conditionally compile code based on the API version? I was looking for a compile time conditional I could then use #if's with, but I can't seem to find one. A release version #define would work too, although not be as nice as the per file semver one. I did find these are generated: #ifdef vl_api_version_tuple vl_api_version_tuple(ipsec.api, 3, 0, 0) #endif /* vl_api_version_tuple */ but I dont know how to utilize this during CPP in an #if conditional Thanks, Chris.-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15602): https://lists.fd.io/g/vpp-dev/message/15602 Mute This Topic: https://lists.fd.io/mt/71604387/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
