w() returns u64 type data.
> And we are updating max clocks spent by a node in vlib_node_runtime_t
> using these timestamps.
>
> Why are we using u32 types in vlib_node_runtime_t?
> Because of this, it can only hold data within 2 seconds and anything above
> 32 bit ra
lib_node_runtime_update_stats(...)
>
>
>
> *From:* Nagaraju Vemuri
> *Sent:* Friday, March 27, 2020 12:54 PM
> *To:* Dave Barach (dbarach)
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] clocks stored in vlib_node_runtime_t #vpp
> #counters
>
>
>
> Thanks fo
g to wait that long. đ...
>
>
>
> âelog trace dispatchâ
>
> âevent-logger save â
>
>
>
> Refer to this page to see how to view the resulting event log file:
> https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html
>
>
>
> HTH... Dave
&g
Hi Dave,
I am still waiting for your reply.
Appreciate if you can comment.
Thanks,
Nagaraju
On Fri, Mar 27, 2020 at 2:42 PM Nagaraju Vemuri via Lists.Fd.Io
wrote:
> Thanks for pointing out elog feature.
>
> May I understand why my suggestion is not good enough? (for my
> unders
Hi,
I want to check if perfmon is needed in vpp.
Who uses it? or How to use perfmon plugin exactly?
Is it safe to remove perfmon plugin from vpp, if we decide to not use it?
Thanks,
Nagaraju
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15944):
and it certainly wonât hurt
> anything to disable it.
>
>
>
> Disable the plugin in /etc/vpp/startup.conf if you like.
>
>
>
> Dave
>
>
>
> *From:* vpp-dev@lists.fd.io *On Behalf Of *Nagaraju
> Vemuri
> *Sent:* Monday, March 30, 2020 3:40 PM
> *T
Hi,
We are using linux bridge to connect different interfaces owned by different
VPP instances.
When the bridge has no binding info about MAC-to-port, bridge is flooding
packets to all interfaces.
Hence VPP receives some packets whose MAC address is owned by some other VPP
instance.
We want to
>received and forwarded.
>
>
>
> Regards,
>
> John
>
>
>
> *From:* vpp-dev@lists.fd.io *On Behalf Of *Nagaraju
> Vemuri
> *Sent:* Tuesday, June 02, 2020 8:13 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] VPP forwarding packets not destined to it #v
C address:
>
> https://gerrit.fd.io/r/c/vpp/+/27027
>
> https://gerrit.fd.io/r/c/vpp/+/27311
>
>
>
> Perhaps it is the issue you are hitting.
>
>
>
> Regards,
>
> John
>
>
>
> *From:* Nagaraju Vemuri
> *Sent:* Wednesday, June 03, 2020 1:06 PM
> *
environment and give the
> feedback whether Johnâs fix addresses the issue you are seeing ?
>
> --a
>
> On 3 Jun 2020, at 19:23, Nagaraju Vemuri wrote:
>
> ï»ż
> Thanks John.
>
> Which release will have your fixes?
>
>
> On Wed, Jun 3, 2020 at 10:21 AM John Lo (loj
ets
> with unicast DMAC which does not match interface MAC. If you can
> pull/clone the latest VPP, either master or stable/2005 branch, and build,
> the image should have my patch included. Please let us know if it solve
> your problem or not.
>
>
>
> Regards,
>
&g
Only packets with unicast
> DMAC not matching interface MAC are dropped by NIC or ethernet-input
> node.-John
>
>
>
> *From:* Balaji Venkatraman (balajiv)
> *Sent:* Thursday, June 04, 2020 4:55 PM
> *To:* John Lo (loj) ; Nagaraju Vemuri <
> nagarajuiit...@gmai
Hi,
We are using VPP as a container process in kubernetes deployment and there are
other python based containers which talk to VPP.
Sometimes during init time, we see that VPP memory is corrupt(api_main or node
graph elements).
We are yet to identify exact root cause, but thinking if accessing
13 matches
Mail list logo
