[vpp-dev] Return NIC back to linux

Hi I bound 2 NICs to vpp in /etc/vpp/startup.conf file in dpdk{} block! Now, how can i return NIC handling from vpp to Linux? Regards ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Gerrit and git out of sync?

Hi, It seems that git master head points at a gerrit patch merged 10h ago[1]. There have been several recent merges and none show up [2]. Any idea what may be causing this? Thanks, Florin [1] https://git.fd.io/vpp/log/ [2] https://gerrit.fd.io/r/#/q/project:vpp

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

Quick note, for completeness: If you’re planning on discarding all headers up to tcp, the other option would be to move the tcp header forward, since it’s typically smaller than the payload. Florin > On Nov 20, 2017, at 2:07 PM, Florin Coras wrote: > > Hi Justin, > > For discarding options

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

Hi Justin, For discarding options you’ll probably need to write your own function that first recomputes them and then moves the payload closer to the header. tcp_buffer_discard_bytes just chops off payload bytes, as in moves the buffer’s current_data pointer. I don’t think it’s enough for what

Re: [vpp-dev] Anyone using the l2 classify path these days?

Cool. Next time you have time, please go ahead and make the change. I’m planning to use the L2 classify path in a use-case which would never be enabled at the same time as the ACL plugin, so no drama expected. (😉)... From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.i

Re: [vpp-dev] Deprecate [S]NAT APIs

Jon, Thanks will do! Ole > On 20 Nov 2017, at 20:00, Jon Loeliger wrote: > > On Mon, Nov 20, 2017 at 9:59 AM, Neale Ranns (nranns) > wrote: > > From src/plugins/nat/nat.api > > /* > * Old "snat" APIs, will be deprecated after 17.10 > */ > > is it time? > > /neale > > As far as I am co

Re: [vpp-dev] Deprecate [S]NAT APIs

On Mon, Nov 20, 2017 at 9:59 AM, Neale Ranns (nranns) wrote: > > From src/plugins/nat/nat.api > > /* > * Old "snat" APIs, will be deprecated after 17.10 > */ > > is it time? > > /neale > As far as I am concerned, they can go now! Thanks, jdl ___ vpp

Re: [vpp-dev] Anyone using the l2 classify path these days?

Dear Dave, ACL plugin is using l2 classify path for traffic diversion and also dispatching the dot1q/dot1ad packets to the correct ip4/ip6 acl plugin node by matching on the inner ethertype... I could probably make use of this change to push some more intelligence of the stateless traffic matc

Re: [vpp-dev] Anyone using the l2 classify path these days?

Hi Dave, By "e0->metadata", do you mean the u16 metadata field from the vnet_classify_entry_t struct and you would like to copy it to a field in vnet buffer l2_classify struct? If storage and consumption of metadata are in the same feature node, I do not see obvious problems as I am guessing u

[vpp-dev] Deprecate [S]NAT APIs

>From src/plugins/nat/nat.api /* * Old "snat" APIs, will be deprecated after 17.10 */ is it time? /neale ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Anyone using the l2 classify path these days?

Dear John, I'm wondering about copying e0->metadata into vlib_buffer (b)->l2_classify.xxx in l2_input_classify. On the face of it, that seems reasonable. Do you see obvious problems with that idea? Related question, for vpp-dev: is anyone using L2 input or output classification these days?

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

Hi Florin, Sorry for the late response. In fact, you just confirmed what I expected, thank you. I'll go with my own parser to include all options (even the reserved ones), inspired by tcp_options_parse. I'll go with my own rewriter too, inspired by tcp_options_write. But, what about discarded

Re: [vpp-dev] Import/includes in .api files

Would some variant of the usual C / C++ guitar lick work? #ifndef __defined_my_types #define __defined_my_types #include #endif /* __defined_my_types */ -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Monday, November 20, 2017 10:32 AM To: Dave Barach (dbarach)

Re: [vpp-dev] Import/includes in .api files

Dave, > Since the beginning of time, we've been running .api files through the C > preprocessor. Put all of your "typeonly..." definitions in a file, and > #include it. Should work immediately. > > Thanks to Damjan, there's only one copy of the suffix rule, in > .../src/suffix-rules.mk. Here's

Re: [vpp-dev] vpp payload modification

“It depends...” If you’re using DPDK devices and a 1500-byte MTU, the answer is almost certainly “no.” Simply set b->current_length += delta, fix checksums, done. The worst-case: added data spans the end of the current packet buffer chain and the beginning of a new buffer. If you need to go the

Re: [vpp-dev] hi vpp-dev, another question about hugepage

Hello, Apologies for not answering your query, however is there any chance you could stop pasting images all the time? Cut-and-paste will suffice. Including images will routinely trip the list-max-message-size limits. Besides, text is searchable and images are not, thus limiting the usefulness

[vpp-dev] hi vpp-dev, another question about hugepage

Hi vpp-dev: I configure the 1G hugepage in /boot/grub2/grub.cfg and split cpu core. Then I configure the /etc/sysctl.d/80-vpp.conf. After reboot the kernel was crash. How can I configure the vpp hugepage? Thank you very much.

[vpp-dev] vpp payload modification

Hello, I am working on vpp version 17.07, i have a case where in i need to change the payload of a packet, if the size of payload is increased ( say like increased by 10 bytes) from the original one do i have to reallocate the buffer to accommodate the extra bytes ? Right now the modified paylo

Re: [vpp-dev] Import/includes in .api files

What Ole said. This requires careful thought for impact to downstream API users. Chris. > -Original Message- > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On > Behalf Of Ole Troan > Sent: Monday, November 20, 2017 8:17 AM > To: Dave Barach (dbarach) > Cc: vpp-

Re: [vpp-dev] Import/includes in .api files

> Since the beginning of time, we've been running .api files through the C > preprocessor. Put all of your "typeonly..." definitions in a file, and > #include it. Should work immediately. But not for any of the other language bindings... Ole > > Thanks to Damjan, there's only one copy of the

Re: [vpp-dev] Import/includes in .api files

Dear Neale, Since the beginning of time, we've been running .api files through the C preprocessor. Put all of your "typeonly..." definitions in a file, and #include it. Should work immediately. Thanks to Damjan, there's only one copy of the suffix rule, in .../src/suffix-rules.mk. Here's the r

[vpp-dev] DPDK 17.11

DPDK 17.11 support is merged this morning but it is still not default. Before making it default, will be good if people can give it a try and report issues. It is as simple as: make dpdk-install-dev DPDK_VERSION=17.11 Thanks, — Damjan ___ vpp-dev

[vpp-dev] hi vpp-dev, need you help!

Hi guys: Need you help! The vpp-devel-17.10-release.x86_64.rpm conflicted with vpp-dpdk-devel-17.08-vpp2.x86_64 when I installed the rpm package. Both vpp-devel and vpp-dpdk-devel have the same directory "/usr/include/dpdk". My environment was real server + centos7.4 and the vpp's version

Re: [vpp-dev] ACL

Assuming your input interface is a subinterface then you would need the build which includes https://gerrit.fd.io/r/#/c/8519/ - and if that is the case already, then I would need to see the full sequence of steps needed to recreate the problem, to say something about it. --a > On 19 Nov 2017,

[vpp-dev] RFC: Import/includes in .api files

Hi All, I’d like to be able to re-use types defined in one .api file in many other .api files. My specific objective is to re-use a fib_path_t across the many APIs that describe a destination to which to send packets. My first attempt at this is: https://gerrit.fd.io/r/#/c/9489/ I updated v