Re: [vpp-dev] Is there a convenient way to name generated files when making VPP, such as rpm

Github is just a mirror which may be up to date with latest VPP software and also github is not the correct repo to work with VPP software. Please use the command below to get latest VPP software. git clone https://gerrit.fd.io/r/vpp In vpp root directory, type "sudo make install-deps". T

[vpp-dev] Is there a convenient way to name generated files when making VPP, such as rpm

Hi, I got VPP code via "git clone -b v20.09 https://github.com/FDio/vpp.git";. When "make pkg-rpm", the generated VPP rpms are named by git tag v20.09 and looked like "vpp-20.09-release.x86_64.rpm". We are using VPP as a sub-project in our project and we have our own git tag format not like VP

[vpp-dev] tests - attach debug option available

Hi all, I implemented a new debug option for make test called ‘attach’. This has been requested a couple of times over the last few months and while it has some drawbacks, it also has advantages. It’s not merged yet. https://gerrit.fd.io/r/c/vpp/+/31663 As always make test-help is full of clu

Re: [vpp-dev] UDP data corruption and MTU issues

Hi Ivan, > On Mar 16, 2021, at 8:51 AM, Ivan Shvedunov wrote: > > Thanks for clearing things up :) Thanks for bringing this up ;-) > Concerning our use case: it's about PFCP protocol [1] that's used in the 5G / > LTE CUPS setting. High throughput is usually not important there as that's a

Re: [vpp-dev] UDP data corruption and MTU issues

Thanks for clearing things up :) Concerning our use case: it's about PFCP protocol [1] that's used in the 5G / LTE CUPS setting. High throughput is usually not important there as that's a control protocol but sometimes it happens to produce rather large UDP packets. We use PFCP in our VPP-based pro

Re: [vpp-dev] UDP data corruption and MTU issues

Hi Ivan, > On Mar 16, 2021, at 6:40 AM, Ivan Shvedunov wrote: > > Hi Florin, > > (inline) > > On Mon, Mar 15, 2021 at 10:27 PM Florin Coras > wrote: >> On Mar 15, 2021, at 9:08 AM, Ivan Shvedunov > > wrote: >> >> Hello, >> >> I'v

Re: [vpp-dev] UDP data corruption and MTU issues

Hi Florin, (inline) On Mon, Mar 15, 2021 at 10:27 PM Florin Coras wrote: > On Mar 15, 2021, at 9:08 AM, Ivan Shvedunov wrote: > > Hello, > > I've noticed a problem in the VPP session layer and posted a patch to > fix it [1]. > Namely, UDP datagrams with length > 1908 that require buffer ch

Re: [vpp-dev] Unexpected behavior of Classifier

You could try the buffer metadata tracking plugin, which should tell you which buffer metadata fields are touched in the graph trajectory you're using. I haven't tested it in a long time, so "caveat emptor." FWIW... Dave -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Benoit

Re: [vpp-dev] Unexpected behavior of Classifier

Hi Jerome, Thanks. If I understand the issue correctly, what you are observing is the classifier does set the correct value in the ip6-inacl node but by the time the packet hits the ip6-hop-by-hop node, this value has been overwritten. If this is correct, the most likely culprit is the union in

[vpp-dev] Suggestion: clarify that github repo is only a mirror, add link to real repo?

Hello, Searching for "VPP source code" using my favourive web search engine gives the github page https://github.com/FDio/vpp as top search result. However that is not the real VPP repo, the github page is only a mirror. I think it would be good to clarify this in the "About" part for the github

[vpp-dev] Error during bring UP of VPP after compilation in Cent OS

Hi All, The following is the error when we try to bring up vpp from compiled path in Cent OS: [root@6464258675a9 bin]# ./vpp[7394]: received signal SIGSEGV, PC 0x7fede345f78a, faulting address 0x0 ./vpp[7394]: received signal SIGSEGV, PC 0x7fede345f78a, faulting address 0x0 ./vpp[7394]: #0 0x0

[vpp-dev] Problem in create sub-interface

I want to test the sub-interface, how can I add a trunk port? Is the following command correct? create sub-interfaces default - Adding the default parameter indicates that packets with VLAN IDs that do not match any other subinterfaces should be sent to this subinterface. I've tested it with fo