[vpp-dev] VPP binary API/VPP_API_TEST program
Hi, I am seeing issues when I run the following commands in vpp_api_test. The following commands return none. In spite, there are routes and interfaces configured on vpp. vat# sw_interface_dump vat# ip_route_dump vat# The following command is not giving full details vat# ikev2_profile_dump profile pr1 local id-type data ip4-addr 0.0.0.0 remote id-type data ip4-addr 0.0.0.0 local traffic-selector addr 0.0.0.0 - 0.0.0.0 port 0 - 65535 protocol 0 remote traffic-selector addr 0.0.0.0 - 0.0.0.0 port 0 - 65535 protocol 0 responder idx 1 0.0.0.0 ike-crypto-alg aes-cbc 256 ike-integ-alg sha1-96 ike-dh modp-2048 esp-crypto-alg aes-cbc 256 esp-integ-alg sha1-96 lifetime 360 jitter 10 handover 5 maxdata 0 IKEv2 profile displays id data and selector data as zero in spite they are set. I am seeing this issue following VPP version version: 21.06.0-1 Regards, Satish K Amara -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20235): https://lists.fd.io/g/vpp-dev/message/20235 Mute This Topic: https://lists.fd.io/mt/85957938/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, Unknown Error Message
Ok, now it worked after modifying the startup.conf file. nNow I face another issue with dslite configuration, lol On Sun, Sep 26, 2021 at 1:10 PM Ole Troan wrote: > > > > On 26 Sep 2021, at 10:43, Ameen Al-Azzawi > wrote: > > > > Note: The below command shows no plugins when I run it. > > > > [root@localhost vpp_plugins]# vppctl show plugins > > Plugin path is: > /usr/lib/x86_64-linux-gnu/vpp_plugins:/usr/lib/vpp_plugins > > > > Plugin Version > Description > > There’s your problem… > Perhaps show log will give an indication why plugins aren’t loaded? > > Cheers, > Ole -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20234): https://lists.fd.io/g/vpp-dev/message/20234 Mute This Topic: https://lists.fd.io/mt/85875423/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] rx-miss while sending packets to Interface (IMPORTANT)
Hi Mathew, Thank you for your valuable response! Yes I have only one tunnel with complete 1 GBPS traffic flowing to the interface. So, My testing is only for one tunnel and not multiple tunnels. So, How can I bypass this rx-miss or split this work among all the available worker threads or any other way to solve this problem? Is there any NIC related points out here for this issue ? Please let me know if there are any solutions , mates. Thanks, Akash On Wed, Sep 29, 2021 at 8:13 PM Matthew Smith wrote: > > I saw two noteworthy items in your 'vppctl show runtime' output: > > 1. All of the packets received/processed appear to be handled by the > gtpu4-input node. They also all appear to be received/handled by a single > worker thread. > 2. Nearly all of the packets are being dropped. I mean the packets that > were actually received and processed - not the packets that were counted as > an rx-miss. > > Regarding #1 - > > I imagine that one thread might be receiving all inbound packets because > you're sending across a single GTPU tunnel (i.e. a single stream). If this > is true, AFAIK most NICs will hash all of the packets to the same queue. > This means you will likely be constrained to handling however many packets > can be handled by a single thread and increasing the number of workers or > rx queues won't help. You might be able to utilize multiple workers/queues > by sending across multiple tunnels. I know very little about GTPU use > cases so I don't know whether it's practical for you to use multiple > tunnels. > > Regarding #2 - > > Out of 8004674 packets received by dpdk-input, 7977696 packets end up > being dropped by error-drop. It would probably be useful to look at a > packet trace and see what node is sending the packets to error-drop. If > packets are being passed to error-drop by gtpu4-input, maybe they do not > match any configured tunnel. > > -Matt > > > On Tue, Sep 28, 2021 at 9:24 AM Akash S R > wrote: > >> Hello, >> >> I have tried increasing the workers from 2 to 5 and rx/tx queues from >> 1024 (default) to 2048 ,also decreasing till 256 but of no use. >> As you told, vector is very high (> 100). Please let us know if there is >> any other way or reason for the same. >> >> >> Thread 1 vpp_wk_0 (lcore 2) >> Time 41.3, 10 sec internal node vector rate 79.42 loops/sec 3628.25 >> vector rates in 1.9388e5, out 6.5319e2, drop 1.9322e5, punt 0.e0 >> Name State Calls Vectors >> Suspends Clocks Vectors/Call >> TenGigabitEthernet4/0/0-output active 19735 >> 26978 0 2.12e31.37 >> TenGigabitEthernet4/0/0-tx active 19735 >> 26969 0 1.43e31.37 >> dpdk-input polling 10241833 >> 8004674 0 2.81e3 .78 >> drop active 92422 >> 7977696 0 1.31e3 86.32 >> error-drop active 92422 >> 7977696 0 6.82e1 86.32 >> ethernet-input active 93109 >> 8004674 0 1.84e2 85.97 >> gtpu4-input active 93106 >> 8004671 0 3.29e2 85.97 >> ip4-drop active 2 >> 2 0 1.33e41.00 >> ip4-inputactive 93106 >> 8004671 0 6.82e2 85.97 >> ip4-input-no-checksumactive 93106 >> 8004673 0 2.37e2 85.97 >> ip4-localactive 93106 >> 8004671 0 2.66e2 85.97 >> ip4-lookup active 112841 >> 8031651 0 3.55e2 71.18 >> ip4-policer-classify active 93106 >> 8004671 0 1.35e3 85.97 >> ip4-rewrite active 19735 >> 26978 0 2.43e31.37 >> ip4-udp-lookup active 93106 >> 8004671 0 3.17e2 85.97 >> ip6-inputactive 1 >> 1 0 1.99e41.00 >> ip6-not-enabled active 1 >> 1 0 2.59e41.00 >> unix-epoll-input polling 9998 >> 0 0 3.30e30.00 >> --- >> Thread 2 vpp_wk_1 (lcore 3) >> Time 41.3, 10 sec internal node vector rate 0.00 loops/sec 988640.31 >> vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0 >> Name State Calls Vectors >> Suspends Clocks
Re: [vpp-dev] rx-miss while sending packets to Interface (IMPORTANT)
Hey Sathish, Interface type is vfio-pci (10-Gigabit SFI/SFP+ Network Connection 10fb), with rx queue and tx queue of hardware set to 4096 (MAX).. Let me know if anything is known. :) Thanks, Akash On Wed, Sep 29, 2021 at 6:09 PM wrote: > Hi Akash, > > Please let me know what type interface and driver you are using, example > igb_uio, vfio, SRIOV etc? > -- > Regards, > Satish Singh > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20232): https://lists.fd.io/g/vpp-dev/message/20232 Mute This Topic: https://lists.fd.io/mt/85920772/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 Socket API how to use from the application #socket-api #vpp #sock-api
Hi Ole, Any examples for VAPI shared to use binary APIs ? Thanks, Regards, Venu On Thu, 23 Sept 2021 at 00:26, Ole Troan wrote: > Ravi, > > The VPP binary API supports two transports. Shared memory and unix domain > sockets. > VAPI is the C language binding for the binary API. I think it only > supports shared memory now. > > Other language bindings support both or only sockets. > > Cheers, > Ole > > > On 22 Sep 2021, at 20:31, RaviKiran Veldanda > wrote: > > > > Hi Experts, > > I was trying to find out how to use socket-api instead of "VAPI" based > API. > > Can you please provide how to use socket-api any pointer will be a great > help. > > //Ravi > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20231): https://lists.fd.io/g/vpp-dev/message/20231 Mute This Topic: https://lists.fd.io/mt/85796959/21656 Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp Mute #socket-api:https://lists.fd.io/g/vpp-dev/mutehashtag/socket-api Mute #sock-api:https://lists.fd.io/g/vpp-dev/mutehashtag/sock-api Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] question using VPP APIs using vac layer
Hi All, i) want to use C APIs. ii) want to have vpp-client proxy which forward API messages to the VPP iii) towards VPP is the binary APIs , intent is use vac_connect, iv) VPP + this application will run in a pod. v) south another would send those APIs recieved by fastpath pod and send it to VPP. So any examples to refer in vpp or external projects ? Thanks, Regards Venu -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20230): https://lists.fd.io/g/vpp-dev/message/20230 Mute This Topic: https://lists.fd.io/mt/85950329/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] rx-miss while sending packets to Interface (IMPORTANT)
I saw two noteworthy items in your 'vppctl show runtime' output: 1. All of the packets received/processed appear to be handled by the gtpu4-input node. They also all appear to be received/handled by a single worker thread. 2. Nearly all of the packets are being dropped. I mean the packets that were actually received and processed - not the packets that were counted as an rx-miss. Regarding #1 - I imagine that one thread might be receiving all inbound packets because you're sending across a single GTPU tunnel (i.e. a single stream). If this is true, AFAIK most NICs will hash all of the packets to the same queue. This means you will likely be constrained to handling however many packets can be handled by a single thread and increasing the number of workers or rx queues won't help. You might be able to utilize multiple workers/queues by sending across multiple tunnels. I know very little about GTPU use cases so I don't know whether it's practical for you to use multiple tunnels. Regarding #2 - Out of 8004674 packets received by dpdk-input, 7977696 packets end up being dropped by error-drop. It would probably be useful to look at a packet trace and see what node is sending the packets to error-drop. If packets are being passed to error-drop by gtpu4-input, maybe they do not match any configured tunnel. -Matt On Tue, Sep 28, 2021 at 9:24 AM Akash S R wrote: > Hello, > > I have tried increasing the workers from 2 to 5 and rx/tx queues from 1024 > (default) to 2048 ,also decreasing till 256 but of no use. > As you told, vector is very high (> 100). Please let us know if there is > any other way or reason for the same. > > > Thread 1 vpp_wk_0 (lcore 2) > Time 41.3, 10 sec internal node vector rate 79.42 loops/sec 3628.25 > vector rates in 1.9388e5, out 6.5319e2, drop 1.9322e5, punt 0.e0 > Name State Calls Vectors >Suspends Clocks Vectors/Call > TenGigabitEthernet4/0/0-output active 19735 26978 > 0 2.12e31.37 > TenGigabitEthernet4/0/0-tx active 19735 26969 > 0 1.43e31.37 > dpdk-input polling 10241833 8004674 > 0 2.81e3 .78 > drop active 92422 7977696 > 0 1.31e3 86.32 > error-drop active 92422 7977696 > 0 6.82e1 86.32 > ethernet-input active 93109 8004674 > 0 1.84e2 85.97 > gtpu4-input active 93106 8004671 > 0 3.29e2 85.97 > ip4-drop active 2 2 > 0 1.33e41.00 > ip4-inputactive 93106 8004671 > 0 6.82e2 85.97 > ip4-input-no-checksumactive 93106 8004673 > 0 2.37e2 85.97 > ip4-localactive 93106 8004671 > 0 2.66e2 85.97 > ip4-lookup active 112841 8031651 > 0 3.55e2 71.18 > ip4-policer-classify active 93106 8004671 > 0 1.35e3 85.97 > ip4-rewrite active 19735 26978 > 0 2.43e31.37 > ip4-udp-lookup active 93106 8004671 > 0 3.17e2 85.97 > ip6-inputactive 1 1 > 0 1.99e41.00 > ip6-not-enabled active 1 1 > 0 2.59e41.00 > unix-epoll-input polling 9998 0 > 0 3.30e30.00 > --- > Thread 2 vpp_wk_1 (lcore 3) > Time 41.3, 10 sec internal node vector rate 0.00 loops/sec 988640.31 > vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0 > Name State Calls Vectors >Suspends Clocks Vectors/Call > dpdk-input polling 37858263 0 > 0 1.14e30.00 > unix-epoll-input polling 36940 0 > 0 3.54e30.00 > --- > Thread 3 vpp_wk_2 (lcore 4) > Time 41.3, 10 sec internal node vector rate 0.00 loops/sec 983700.23 > vector rates in 4.8441e-2, out 0.e0, drop 4.8441e-2, punt 0.e0 >
Re: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to 21.06 version
The cleanest solution would be to write a wrapper for each one of those autogenerated functions, and mark the wrapper as __clib_export Best regards Mohammed > On 29 Sep 2021, at 15:46, Satya Murthy wrote: > > This works fine for me where the code is fully written by us. > But, I have few functions which are kind of generated routines from a third > party library, where we do not have control to add this __clib_export. > Is there any way to work around this case? > > -- > Thanks & Regards, > Murthy > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20228): https://lists.fd.io/g/vpp-dev/message/20228 Mute This Topic: https://lists.fd.io/mt/85945383/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] vlib_get_plugin_symbol returning null after upgrading to 21.06 version
This works fine for me where the code is fully written by us. But, I have few functions which are kind of generated routines from a third party library, where we do not have control to add this __clib_export. Is there any way to work around this case? -- Thanks & Regards, Murthy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20227): https://lists.fd.io/g/vpp-dev/message/20227 Mute This Topic: https://lists.fd.io/mt/85945383/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] vlib_get_plugin_symbol returning null after upgrading to 21.06 version
Thanks Mohammed and Dave for the quick inputs. Adding __clib_export solved my issue. -- Thanks & Regards, Murthy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20226): https://lists.fd.io/g/vpp-dev/message/20226 Mute This Topic: https://lists.fd.io/mt/85945383/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] upcoming change in nat44-ed static mapping API
On Tue, Sep 28, 2021 at 5:50 AM Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco) wrote: > Hi Matt/vpp-dev, > > I’m reaching out after discussion with Andrew regarding an upcoming change > in behaviour of an API. Currently, when > nat44_ed_add_del_static_mapping[_v2] is called, the supplied u8 protocol > value is taken and silently converted into > NAT_PROTOCOL_(TCP|UDP|ICMP|OTHER). Part of upcoming change is to drop this > internal enum and treat static mappings (SM) same way as dynamic mappings - > to store IANA IP protocol value in SM instead of said nat_protocol_t. This > however causes a behaviour change. > > For TCP, UDP and ICMP there is NO change. For everything else the change > is: > > Old: > > nat44_ed_add_del_static_mapping (is_add=1, protocol=101) is treated as > "nat44_ed_add_del_static_mapping (protocol=other)", so this creates a > catch-almost-all SM, which then translates also all other protocols except > tcp, udp and icmp. Calling nat44_ed_add_del_static_mapping (is_add=1, > protocol=102) would then return VNET_API_ERROR_VALUE_EXIST (because it’s > internally translated to the same “other” thingie). > > New: > > protocol is stored in (and matched by) static mapping exactly as it’s > supplied. To get old behaviour a user would have to create 252 static > mappings (with all protocol values except tcp, udp, icmp). New feature with > this is ability to translate only some of non-tcp/udp/icmp protocols as it > isn’t a catch-almost-all logic anymore. > > Question is whether there is a real need to do the usual deprecate old api > and keep its behaviour (which would now internally add/del 252 mappings) > while introducing a new api with new behaviour routine or it’s okay to > change it under the hood keeping apis intact. The apis are already > accepting ip protocol value, so there is no change required in api > signature. > > Would you be so kind to share your thoughts on this topic? > > Thanks, > Klement Hi Klement, It's ok with me. Netgate does not have any code that relies on the old behavior. Thanks, -Matt -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20225): https://lists.fd.io/g/vpp-dev/message/20225 Mute This Topic: https://lists.fd.io/mt/85921424/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] vlib_get_plugin_symbol returning null after upgrading to 21.06 version
+1...
From: vpp-dev@lists.fd.io On Behalf Of Mohammed Hawari
Sent: Wednesday, September 29, 2021 8:46 AM
To: Dave Barach
Cc: Satya Murthy ; vpp-dev
Subject: Re: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to
21.06 version
Hi,
Please note that starting with v21.01, plugin symbols are hidden by default and
can’t be used from another plugin (or any other linked object). You need to add
the __clib_export attribute to the symbols you want to expose to other plugins.
For example, in the dns plugin, the dns_resolve_name function is marked with
__clib_export, in file plugins/dns/dns.c:
__clib_export int
dns_resolve_name (u8 *name, dns_cache_entry_t **ep, dns_pending_request_t *t0,
dns_resolve_name_t *rn)
{
This enables its use by the ikev2 plugin. In file plugins/ikev2/ikev2.c you
have
km->dns_resolve_name =
vlib_get_plugin_symbol ("dns_plugin.so", "dns_resolve_name”);
Best regards,
Mohammed
On 29 Sep 2021, at 12:59, Dave Barach mailto:v...@barachs.net> > wrote:
It’s worth checking that the symbol in question is actually exported. As part
of upgrading, you may have started using a different toolchain.
$ nm -go .o | grep
From: vpp-dev@lists.fd.io mailto:vpp-dev@lists.fd.io> > On Behalf Of Satya Murthy
Sent: Wednesday, September 29, 2021 6:43 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to
21.06 version
Hi,
We are trying to upgrade to fdio.2106 version from a previous version.
After upgrading to 21.06 version with our custom plugins, we are seeing that
vlib_get_plugin_symbol() to resolve a symbol from another plugin is always
returning null.
This was working fine in the earlier version.
I cross checked that load_one_plugin() is successful in loading all the
plugins, before we call the vlib_get_plugin_symbol().
Any pointers on what could be happening here ?
--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20224): https://lists.fd.io/g/vpp-dev/message/20224
Mute This Topic: https://lists.fd.io/mt/85945383/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] vlib_get_plugin_symbol returning null after upgrading to 21.06 version
Hi,
Please note that starting with v21.01, plugin symbols are hidden by default and
can’t be used from another plugin (or any other linked object). You need to add
the __clib_export attribute to the symbols you want to expose to other plugins.
For example, in the dns plugin, the dns_resolve_name function is marked with
__clib_export, in file plugins/dns/dns.c:
__clib_export int
dns_resolve_name (u8 *name, dns_cache_entry_t **ep, dns_pending_request_t *t0,
dns_resolve_name_t *rn)
{
This enables its use by the ikev2 plugin. In file plugins/ikev2/ikev2.c you
have
km->dns_resolve_name =
vlib_get_plugin_symbol ("dns_plugin.so", "dns_resolve_name”);
Best regards,
Mohammed
> On 29 Sep 2021, at 12:59, Dave Barach wrote:
>
> It’s worth checking that the symbol in question is actually exported. As part
> of upgrading, you may have started using a different toolchain.
>
> $ nm -go .o | grep
>
> From: vpp-dev@lists.fd.io > On Behalf Of Satya Murthy
> Sent: Wednesday, September 29, 2021 6:43 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to
> 21.06 version
>
> Hi,
>
> We are trying to upgrade to fdio.2106 version from a previous version.
>
> After upgrading to 21.06 version with our custom plugins, we are seeing that
> vlib_get_plugin_symbol() to resolve a symbol from another plugin is always
> returning null.
> This was working fine in the earlier version.
>
> I cross checked that load_one_plugin() is successful in loading all the
> plugins, before we call the vlib_get_plugin_symbol().
>
> Any pointers on what could be happening here ?
>
> --
> Thanks & Regards,
> Murthy
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20223): https://lists.fd.io/g/vpp-dev/message/20223
Mute This Topic: https://lists.fd.io/mt/85945383/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] rx-miss while sending packets to Interface (IMPORTANT)
Hi Akash, Please let me know what type interface and driver you are using, example igb_uio, vfio, SRIOV etc? -- Regards, Satish Singh -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20222): https://lists.fd.io/g/vpp-dev/message/20222 Mute This Topic: https://lists.fd.io/mt/85920772/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] vlib_get_plugin_symbol returning null after upgrading to 21.06 version
It’s worth checking that the symbol in question is actually exported. As part of upgrading, you may have started using a different toolchain. $ nm -go .o | grep From: vpp-dev@lists.fd.io On Behalf Of Satya Murthy Sent: Wednesday, September 29, 2021 6:43 AM To: vpp-dev@lists.fd.io Subject: [vpp-dev] vlib_get_plugin_symbol returning null after upgrading to 21.06 version Hi, We are trying to upgrade to fdio.2106 version from a previous version. After upgrading to 21.06 version with our custom plugins, we are seeing that vlib_get_plugin_symbol() to resolve a symbol from another plugin is always returning null. This was working fine in the earlier version. I cross checked that load_one_plugin() is successful in loading all the plugins, before we call the vlib_get_plugin_symbol(). Any pointers on what could be happening here ? -- Thanks & Regards, Murthy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20221): https://lists.fd.io/g/vpp-dev/message/20221 Mute This Topic: https://lists.fd.io/mt/85945383/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vlib_get_plugin_symbol returning null after upgrading to 21.06 version
Hi, We are trying to upgrade to fdio.2106 version from a previous version. After upgrading to 21.06 version with our custom plugins, we are seeing that vlib_get_plugin_symbol() to resolve a symbol from another plugin is always returning null. This was working fine in the earlier version. I cross checked that load_one_plugin() is successful in loading all the plugins, before we call the vlib_get_plugin_symbol(). Any pointers on what could be happening here ? -- Thanks & Regards, Murthy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20220): https://lists.fd.io/g/vpp-dev/message/20220 Mute This Topic: https://lists.fd.io/mt/85945383/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
