[vpp-dev] Need some help on VPP

Hi all, Thanks for support. I need to know why *vlib_node_runtime_t *nodes_by_type[4]* in structure*vlib_node_main_t*. I am really not understanding what is usage of*runtime nodes*. On Monday 05 June 2017 11:26 PM, Dave Barach (dbarach) wrote: I stand corrected, at least in a general

Re: [vpp-dev] IPv4 Option field

Soheil, Quite some platforms switch the packets with up options in software. An example: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/31sga/configuration/guide/config/mcastmls.html#wp1082100 How do you plan to deal with this behavior in the network ? --a > On 29 Jun

Re: [vpp-dev] IPv4 Option field

> I want to know what this IPv4 Option field affects the end user? Are there > any protocols or user programs that stop working without this? No. Nothing on the Internet. > We, as a communication operator, need to know this issue, because we want to > use VPP as high-loaded NAT instead of

Re: [vpp-dev] Buffer allocation failure

The packet you receive, what do you do with it? If you don’t forward it, you have two choices: * You could deallocate its buffer. * Or, better, recycle it and use that packets buffer for your outgoing packet. That way you avoid the expense of allocating a new one. Chris. From:

[vpp-dev] VPP API / CLI, shared memory vs trivial method.

Why is shared memory is not considered between client(slowpath) and VPP fastpath to pass on the arguments to create session and use vlib API to issue create command pass on the handler/index_into_shared memory to VPP fastpath. I believe that would help in bit complex use cases where there are

Re: [vpp-dev] IPv4 Option field

Ole, We are in the design phase and investigating different platforms to see which one might be used in our scenario. Here, I don't wannna discuss the characteristics of a software router solution we all already know that! But simply one of the key properties of a software solution like VPP

Re: [vpp-dev] IPv4 Option field

The issue is that many existing routers will drop, or if you are very lucky slow-path, and IP4 packets with options. Yes, the specification allows such options. The IPv4 specs even allow adding and removing such options. However, because of issues like ECMP / LAG support, such options have been

Re: [vpp-dev] IPv4 Option field

Joel, At the risk of turning this into the IETF list. > The issue is that many existing routers will drop, or if you are very lucky > slow-path, and IP4 packets with options. > Yes, the specification allows such options. The IPv4 specs even allow adding > and removing such options. > However,

Re: [vpp-dev] IPv4 Option field

Ole, I was taking the permissive view, which has often been taken with IPv4. Your argument that the specs do not permit insertion even in v4 is quite defensible. My point was that even if it is permitted, it is such a bad idea that we do not want to go there. Also, just for clarity, I agree

Re: [vpp-dev] IPv4 Option field

Thanks Andrew for the link, Our use case is something like this: Consider that you have a pool of NFV containers which are connected using a software solution (using Hypervisor, OVS, VPP, or any other approaches). Now from the control point of view we require to have a full knowledge about the

Re: [vpp-dev] IPv4 Option field

Ole, > Now, all this said... I understand the temptation of the solution and while I think it is likely a bad idea, and likely undeployable, nothing would stop you from trying it out in VPP if you like. There is some code that assumes the TCP header follows a 20 byte IP header, but that could

Re: [vpp-dev] IPv4 Option field

I guess you are right, there was a misunderstanding, though in both cases lack of support from the router will lead to the same result, drop of packets! The guys who argue that it is not a good idea might say that from routers point of view generally there would be no difference between the case

Re: [vpp-dev] IPv4 Option field

Just to be clear, Soheil, are you fine with the idea that the options like timestamp are only added at the origination node? Your use of the word "inject" made some people believe that you expected intermediate nodes to add an option, based on the replies I see on this list. Perhaps, by "inject"

Re: [vpp-dev] Buffer allocation failure

Thanks for the help, it works! Alessio On Fri, Jun 30, 2017 at 3:29 PM, Dave Barach (dbarach) wrote: > +1... Thanks… Dave > > > > *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On > Behalf Of *Luke, Chris > *Sent:* Friday, June 30, 2017 8:29 AM >