Re: [vpp-dev] #vpp #vpp-memif #vppcom

On Fri, Dec 11, 2020 at 3:13 PM wrote: > in our application I have to send out multicast packets, but the packet is > getting dropped in vpp > > #vpp #vpp-memif #vppcom Folks, You know, these subject lines are near meaningless. Could we please have real English descriptions, questions or

Re: [vpp-dev] MAINTAINER for extras/rpm?

We currently use CentOS. If that means we have to maintain this, so be it. Jim > On Dec 14, 2020, at 6:42 PM, Paul Vinciguerra > wrote: > >  > Hi Damjen, > > Thanks for approving my change. > > Hi Dave, > > That was what I wanted to understand. I think some folks here may use rpm's.

Re: [vpp-dev] MAINTAINER for extras/rpm?

Hi Damjen, Thanks for approving my change. Hi Dave, That was what I wanted to understand. I think some folks here may use rpm's. If they don't want to take over the responsibility of maintaining the spec, I'm +1 for removing the rpm build and saving the resources on the CI. I just know that

Re: [vpp-dev] MAINTAINER for extras/rpm?

I agree with Damjan.  It was orphaned by the RedHat folks who left the project a long time ago. I'd recommend removing centos support sooner rather than later as it is simply wasting energy at this point. Thanks, -daw- On 12/14/2020 1:57 PM, Paul Vinciguerra wrote: Is the maintenance burden

Re: [vpp-dev] Problem with native avf

> On 07.12.2020., at 22:55, Christian Hopps wrote: > > > >> On Dec 7, 2020, at 3:02 PM, Damjan Marion wrote: >> >> >> >>> On 07.12.2020., at 20:41, Christian Hopps wrote: >>> >>> >>> On Dec 7, 2020, at 1:44 PM, Damjan Marion wrote: > > On 07.12.2020., at 17:02,

Re: [vpp-dev] MAINTAINER for extras/rpm?

Is the maintenance burden the unwanted child, or the RPM itself? Now that it was announced that Centos 8 will be EOL'd at the end of 2021, yet Centos 7 EOL's in 2024, Should we go back to supporting Centos 7 or should we plan to drop the process of building rpms before Centos 8 ends support? On

Re: [vpp-dev] MAINTAINER for extras/rpm?

AFAIK it is unwanted child…. — Damjan > On 14.12.2020., at 18:17, Paul Vinciguerra wrote: > > Is there a maintainer? There is no entry in the Maintainers file. > > https://gerrit.fd.io/r/c/vpp/+/30408 > fixes failures on centos-8 due to an older

[vpp-dev] MAINTAINER for extras/rpm?

Is there a maintainer? There is no entry in the Maintainers file. https://gerrit.fd.io/r/c/vpp/+/30408 fixes failures on centos-8 due to an older cmake package. I'd bet that it probably breaks something that we're not testing, though. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent

Re: [EXT] [vpp-dev] New perfmon plugin

Please find the list of perf events on TX2 and N1SDP attached. Thanks Govind From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion via lists.fd.io Sent: Monday, December 14, 2020 8:03 AM To: Honnappa Nagarahalli Cc: nsax...@marvell.com; vpp-dev ; nd Subject: Re: [EXT] [vpp-dev] New perfmon

Re: [vpp-dev] Please review https://gerrit.fd.io/r/c/vpp/+/29754

Thanks! On Sun, Dec 13, 2020 at 6:48 AM Damjan Marion wrote: > > I reverted that patch. > > — > Damjan > > On 13.12.2020., at 05:23, Paul Vinciguerra > wrote: > > It looks like this change is causing vpp-verify-master-ubuntu1804-aarch64 > jobs to fail in the CI. > > Can someone take a look? >

Re: [EXT] [vpp-dev] New perfmon plugin

Thanks both, So on N1SDP and ThunderX2 we have: armv8_pmuv3_0 In addition ThunderX2 have few uncore_* PMUs On OcteonTX2 we have armv8_cavium_thunder which seems to be different than armv8_pmuv3_0. Will be interesting to see output of “grep . events/*“ so we can compare counter names and

Re: [EXT] [vpp-dev] New perfmon plugin

> > Hi Damjan, > > ARM defines two sets of performance monitoring counters and extension > 1. Common Event number and micro-architecture events defined by ARM > which every chip vendor should implement. > 2. Chip vendor specific PMU counters other than (1) > > I am not in ThunderX2 BU but I

Re: [EXT] [vpp-dev] New perfmon plugin

Hi Damjan, ARM defines two sets of performance monitoring counters and extension 1. Common Event number and micro-architecture events defined by ARM which every chip vendor should implement. 2. Chip vendor specific PMU counters other than (1) I am not in ThunderX2 BU but I think the kernel

Re: [vpp-dev] move to clang-format

Sounds good to me, clang-format should be more consistent than indent... ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion > via lists.fd.io > Sent: dimanche 13 décembre 2020 13:16 > To: vpp-dev > Subject: [vpp-dev] move to clang-format > > > Hi, > > I

Re: [EXT] [vpp-dev] New perfmon plugin

Yes most of the ARM processors including ThunderX2, OCTEONTX2 has PMU as per AARCH64 specifications. I did some analysis to add ARM support in older perfmon plugin and should be easy to port to this new one. This is something in TODO list which is much needed for us and overall ARM Thanks,