Re: [vpp-dev] VPP v22.02 not coming up

[Guangming]

Hi,

I have compiled VPP v22.02 on Centos 8.4. I was able to compile it. But when I 
installed it and modified /etc/vpp/startup.conf, vpp service is not able to 
come up. I added below sections in /etc/vpp/startup.conf:-

dpdk {
socket-mem 1024 dev :00:08.0 dev :00:09.0 dev :00:0a.0 dev 
:00:0b.0
}

plugins {
## Adjusting the plugin path depending on where the VPP plugins are
#       path /ws/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins

## Disable all plugins by default and then selectively enable specific plugins
# plugin default { disable }
# plugin dpdk_plugin.so { enable }
# plugin acl_plugin.so { enable }
plugin linux_cp_plugin.so { enable }
plugin linux_nl_plugin.so { enable }
## Enable all plugins by default and then selectively disable specific plugins
# plugin dpdk_plugin.so { disable }
# plugin acl_plugin.so { disable }
}

linux-cp {
default netns dataplane
interface-auto-create
}

VPP service log is showing error for the highlighted sections:-

vlib_call_all_config_functions: unknown input `dpdk  socket-mem 1024 dev 
:00:08.0 dev :00:09.0 '

vlib_call_all_config_functions: unknown input `linux-cp  default netns 
dataplane interface-auto-create '

I have compiled VPP with all the plugins mentioned above. In 
"/usr/lib/vpp_plugins/" I can see .so files i.e dpdk_plugin.so, 
linux_cp_plugin.so, linux_nl_plugin.so

Can you please help us if we are missing out something?

Thanks and Regards,
Chinmaya Agarwal.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21448): https://lists.fd.io/g/vpp-dev/message/21448
Mute This Topic: https://lists.fd.io/mt/91312985/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query on VPP in Aure

[Matthew Smith via lists.fd.io]

Hi John,

I have had some problems on Azure with my build lately similar to the MTU
errors you mentioned. The build that has problems is based on the
commit b0f0f8c8d ("memif: fix memif_process_desc indexing") from the
upstream master branch (so..master branch from 1 or 2 months ago using DPDK
21.11, not a stable release version of VPP). Last week I applied these
recent patches to my build:

739a342b4 dpdk: fix overflow in mtu arithmetic
b6bf5c9c4 dpdk: clear the RTE_MEMPOOL_F_NON_IO

With those patches applied, the problems may have gone away. Netgate's QA
team is still trying to verify if they can reproduce the issue with the
patches applied. It was intermittent to begin with, so its not
straightforward to declare that the issue is resolved.

The build in our previous release, which did not have any issues with
setting MTUs on Azure netvsc interfaces, was based on commit 895def45c
("avf: fix RSS hash key") from the upstream master branch. The DPDK version
used there was 21.08.

-Matt


On Wed, May 18, 2022 at 12:20 PM Johnny Martinez 
wrote:

> Hello Matt,
>
> Can you *please *confirm which DPDK and VPP versions you have that are
> working in Azure?
>
> I am hoping to get a base build with no errors and the ability to set MTU
> size...
>
> *Thank you in advance for your help!!!*
>
> --
> John M.
>
>
> On Mon, May 2, 2022 at 1:42 PM Matthew Smith  wrote:
>
>>
>> Sorry, there was a typo. You should use DPDK_MLX5_COMMON_PMD=y instead
>> of DPDK_MLX_COMMON_PMD=y.
>>
>> -Matt
>>
>>
>> On Mon, May 2, 2022 at 11:28 AM Johnny Martinez 
>> wrote:
>>
>>> Hello Matt!
>>>
>>> *Thank you very much for the reply!*
>>>
>>> Our end goal is to be using Alma Linux but we went ahead and tried it in
>>> a fresh Ubuntu 20.04 installation with the same result.
>>>
>>> It looks like it is unable to compile the *mlx5 drivers*.
>>>
>>> *I’ve attached the complete build log for your review.*
>>>
>>>
>>>
>>> *Build was started with:*
>>>
>>> *make DPDK_MLX4_PMD=y DPDK_MLX5_PMD=y DPDK_MLX_COMMON_PMD=y pkg-deb |
>>> tee /root/vpp-build.log*
>>>
>>>
>>>
>>> As an extra precaution, the vpp.mk content is:
>>>
>>>
>>>
>>> *MACHINE=$(shell uname -m)*
>>>
>>> *vpp_arch = native*
>>>
>>> *vpp_root_packages = vpp*
>>>
>>> *vpp_debug_TAG_BUILD_TYPE = debug*
>>>
>>> *vpp_TAG_BUILD_TYPE = release*
>>>
>>> *vpp_clang_TAG_BUILD_TYPE = release*
>>>
>>> *vpp_gcov_TAG_BUILD_TYPE = gcov*
>>>
>>> *vpp_coverity_TAG_BUILD_TYPE = coverity*
>>>
>>> *vpp_dpdk_inc_dir = /usr/include/dpdk/*
>>>
>>> *vpp_dpdk_lib_dir = /usr/lib64/*
>>>
>>> *vpp_uses_dpdk_mlx4_pmd = yes*
>>>
>>> *DPDK_MLX4_PMD=y*
>>>
>>> *DPDK_MLX5_PMD=y*
>>>
>>> *DPDK_MLX_COMMON_PMD=y*
>>>
>>>
>>>
>>> The build completes, but there’s an issue with the MLX5 driver. As seen
>>> in the build log, the *MLX4 is built, but MLX5 is not*. I’ve tried
>>> searching online, but there’s reference to *glue* with regard to the
>>> MLX5, but nothing actionable I could find:
>>>
>>>
>>>
>>> *Part 1: Shows that the library “mlx4” and “mlx5” are included as part
>>> of “make” (means our build options were correctly interperated):*
>>>
>>>
>>>
>>> *cmake3 --build
>>> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/build-rdma-core
>>> -- libccan.a libibverbs.a librdma_util.a libmlx5.a libmlx4.a >
>>> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/rdma-core.build.log*
>>>
>>> *sed 's/^Libs.private:.*/Libs.private: -lmlx4 -lmlx5 -libverbs
>>> -lrdma_util -lccan -lpthread/' -i
>>> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/build-rdma-core/lib/pkgconfig/libibverbs.pc
>>> >>
>>> /root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/build-vpp-native/external/rdma-core.build.log*
>>>
>>>
>>> *Part 2: Shows that MLX5 is missing “common_mlx5” (which I can’t find a
>>> way to install…?) so is disabled. MLX4 however, is built:*
>>>
>>>
>>>
>>> *Using 'PKG_CONFIG_PATH' from environment with value:
>>> '/root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/install-vpp-native/external/lib/pkgconfig'*
>>>
>>> *Run-time dependency libmlx4 found: YES 1.0.39.1*
>>>
>>> *Using 'PKG_CONFIG_PATH' from environment with value:
>>> '/root/azure/vpp/build-root/rpmbuild/vpp-22.06/build-root/install-vpp-native/external/lib/pkgconfig'*
>>>
>>> *Run-time dependency libibverbs found: YES 1.14.39.1*
>>>
>>> *Compiler for C supports arguments -std=c11: YES*
>>>
>>> *Compiler for C supports arguments -Wno-strict-prototypes
>>> -Wstrict-prototypes: YES*
>>>
>>> *Compiler for C supports arguments -D_BSD_SOURCE: YES*
>>>
>>> *Compiler for C supports arguments -D_DEFAULT_SOURCE: YES*
>>>
>>> *Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES*
>>>
>>> *Header  has symbol
>>> "MLX4DV_SET_CTX_ATTR_BUF_ALLOCATORS" with dependencies libmlx4, libibverbs:
>>> YES*
>>>
>>> *Header  has symbol
>>> "MLX4DV_QP_MASK_UAR_MMAP_OFFSET" with dependencies libmlx4, libibverbs: YES*
>>>
>>> *Checking whether type "struct mlx4_wqe_lso_seg" 

[vpp-dev] What's New in Calico v3.23

[Jerome Tollet via lists.fd.io]

People is this list will certainly be interested in this announcement 
https://www.tigera.io/blog/whats-new-in-calico-v3-23/
Regards,
Jerome

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21446): https://lists.fd.io/g/vpp-dev/message/21446
Mute This Topic: https://lists.fd.io/mt/91319905/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP v22.02 not coming up

[Pim van Pelt]

Hoi,

Linux CP's "interface-auto-create" flag is no longer valid. Currently you
can use the following CLI options (see src/plugins/linux-cp/lcp_cli.c):
  .short_help = "lcp create | host-if  "
  .short_help = "lcp lcp-sync [on|enable|off|disable]",
  .short_help = "lcp lcp-auto-subint [on|enable|off|disable]",
  .short_help = "lcp param [del-static-on-link-down
(on|enable|off|disable)] "
  .short_help = "lcp default netns []",
  .short_help = "lcp delete |",
  .short_help = "show lcp [phy ]",

And you can use the following startup.conf options (see
src/plugins/linux-cp/lcp_interface.c):
  if (unformat (input, "default netns %v", _ns))
  else if (unformat (input, "lcp-auto-subint"))
  else if (unformat (input, "lcp-sync"))
  else if (unformat (input, "del-static-on-link-down"))
  else if (unformat (input, "del-dynamic-on-link-down"))

Also please be aware that LinuxCP changed substantially between 22.02 and
(upcoming) 22.06. I recommend you use HEAD or the 22.06 release candidate
to benefit from these improvements and changes.


On Tue, May 24, 2022 at 5:08 PM Chinmaya Aggarwal 
wrote:

> Hi,
>
> I have compiled VPP v22.02 on Centos 8.4. I was able to compile it. But
> when I installed it and modified /etc/vpp/startup.conf, vpp service is not
> able to come up. I added below sections in /etc/vpp/startup.conf:-
>
> dpdk {
> socket-mem 1024 dev :00:08.0 dev :00:09.0 dev :00:0a.0 dev
> :00:0b.0
> }
>
> plugins {
> ## Adjusting the plugin path depending on where the VPP plugins are
> #   path
> /ws/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
>
> ## Disable all plugins by default and then selectively enable
> specific plugins
> # plugin default { disable }
> # plugin dpdk_plugin.so { enable }
> # plugin acl_plugin.so { enable }
> plugin linux_cp_plugin.so { enable }
> plugin linux_nl_plugin.so { enable }
> ## Enable all plugins by default and then selectively disable
> specific plugins
> # plugin dpdk_plugin.so { disable }
> # plugin acl_plugin.so { disable }
> }
>
> linux-cp {
>   default netns dataplane
>   interface-auto-create
> }
>
> VPP service log is showing error for the highlighted sections:-
>
> vlib_call_all_config_functions: unknown input `dpdk  socket-mem 1024 dev
> :00:08.0 dev :00:09.0 '
>
> vlib_call_all_config_functions: unknown input `linux-cp  default netns
> dataplane interface-auto-create '
>
> I have compiled VPP with all the plugins mentioned above. In
> "/usr/lib/vpp_plugins/" I can see .so files
> i.e dpdk_plugin.so, linux_cp_plugin.so, linux_nl_plugin.so
>
> Can you please help us if we are missing out something?
>
> Thanks and Regards,
> Chinmaya Agarwal.
>
>
>
> 
>
>

-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21445): https://lists.fd.io/g/vpp-dev/message/21445
Mute This Topic: https://lists.fd.io/mt/91312985/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP v22.02 not coming up

[Chinmaya Aggarwal]

Hi,

I have compiled VPP v22.02 on Centos 8.4. I was able to compile it. But when I 
installed it and modified /etc/vpp/startup.conf, vpp service is not able to 
come up. I added below sections in /etc/vpp/startup.conf:-

dpdk {
socket-mem 1024 dev :00:08.0 dev :00:09.0 dev :00:0a.0 dev 
:00:0b.0
}

plugins {
## Adjusting the plugin path depending on where the VPP plugins are
#       path /ws/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins

## Disable all plugins by default and then selectively enable specific plugins
# plugin default { disable }
# plugin dpdk_plugin.so { enable }
# plugin acl_plugin.so { enable }
plugin linux_cp_plugin.so { enable }
plugin linux_nl_plugin.so { enable }
## Enable all plugins by default and then selectively disable specific plugins
# plugin dpdk_plugin.so { disable }
# plugin acl_plugin.so { disable }
}

linux-cp {
default netns dataplane
interface-auto-create
}

VPP service log is showing error for the highlighted sections:-

vlib_call_all_config_functions: unknown input `dpdk  socket-mem 1024 dev 
:00:08.0 dev :00:09.0 '

vlib_call_all_config_functions: unknown input `linux-cp  default netns 
dataplane interface-auto-create '

I have compiled VPP with all the plugins mentioned above. In 
"/usr/lib/vpp_plugins/" I can see .so files i.e dpdk_plugin.so, 
linux_cp_plugin.so, linux_nl_plugin.so

Can you please help us if we are missing out something?

Thanks and Regards,
Chinmaya Agarwal.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21444): https://lists.fd.io/g/vpp-dev/message/21444
Mute This Topic: https://lists.fd.io/mt/91312985/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] zero memcpy interface (alternative to memif) to pass packets from VPP to another trusted DPDK application

[PRANAB DAS]

Thank you Damjan. Really appreciate it. I got the idea. Let me look into
the snort plugin code and experiment and get back to you should I have any
questions.

-  PK Das

On Tue, May 24, 2022 at 8:51 AM Damjan Marion  wrote:

>
> On 24.05.2022., at 14:28, PRANAB DAS  wrote:
>
> Hi Damjan,
>
> The snort plugin could be simple. But I am not familiar with VPP
> memory/buffer management as such and I am finding it not so easy to
> navigate.
> And looking at the physmem.c/h code, it appears the VPP uses heap memory
> (mmap) and has its own heap/buffer management system.
>
>
> VPP uses mmap system call (same like DPDK) to map shared memory, but that
> is not heap memory.
>
> VPP buffer memory is shared memory (typically hugepage backed). There is
> one block of shared memory per NUMA, and each block have own FD.
> VPP can pass that FD to remote app over UDS and remote app can simply map
> that shared memory, Both memif and snort plugins do exactly that.
>
> Main complexity is creating another shared memory region which holds
> enqueue and dequeue rings: In snort plugin you can see how that shared
> memory is orgaised by looking at src/plugins/snort/daq_vpp.h
>
>
> Could you clarify? And in the snort plugin exposes/shares the mmap memory
> region to the external program (snort). Is there any documentation that
> provides an overview of VPP buffer management and how VPP memory/buffers
> can be shared with external trusted applications?
>
>
> No, unfortunately there is no documentation, but there is running code
> (snort plugin) which does exactly that.
> If you have any questions, ask here and i will try to help.
>
>
> Thank you
>
> - PK Das
>
>
>
>
> On Tue, May 24, 2022 at 7:51 AM Damjan Marion  wrote:
>
>>
>> VPP is not DPDK application, VPP features doesnt maintain DPDK metadata,
>> in many cases we use native drivers so DPDK is not even loaded so you
>> cannot use rte_ring unless you want to write complete translation layer
>> which will likely be significantly slower that using native way which snort
>> plugin uses.
>>
>> Why do you think zero copy interface in snort plugin is not simple?
>>
>> —
>> Damjan
>>
>> On 24.05.2022., at 13:34, PRANAB DAS  wrote:
>>
>> 
>> Thank you very much for your response Benoit!
>> I am wondering if there is another option e.g. rte-ring of DPDK or if
>> that option is not feasible in VPP?
>> Could you comment? We are looking for a service-chaining application
>> similar to snort but would like to have a much simpler zero-copy interface.
>>
>> Thank you,
>>
>> - P K DAS
>>
>> On Tue, May 24, 2022 at 4:22 AM Benoit Ganne (bganne) 
>> wrote:
>>
>>> It all depends on what you want to do. Usually, we try to avoid sharing
>>> buffers read/write between multiple process, it makes debugging much harder
>>> - especially buffer leaks or use-after-free...
>>> Here is an example to share VPP buffers read-only with snort so that
>>> snort can inspect traffic and gives a verdict back without any copy:
>>> https://git.fd.io/vpp/tree/src/plugins/snort
>>>
>>> Best
>>> ben
>>>
>>> > -Original Message-
>>> > From: vpp-dev@lists.fd.io  On Behalf Of PRANAB
>>> DAS
>>> > Sent: Monday, May 23, 2022 20:11
>>> > To: vpp-dev@lists.fd.io
>>> > Subject: Re: [vpp-dev] zero memcpy interface (alternative to memif) to
>>> > pass packets from VPP to another trusted DPDK application
>>> >
>>> > Hi
>>> >
>>> > Could some one comment on zero-copy alternative to memif interface? Any
>>> > ideas, comments are welcome.
>>> >
>>> > Thank you
>>> >
>>> > - Pranab K Das
>>>
>>
>> 
>>
>>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21443): https://lists.fd.io/g/vpp-dev/message/21443
Mute This Topic: https://lists.fd.io/mt/91252298/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] zero memcpy interface (alternative to memif) to pass packets from VPP to another trusted DPDK application

[Damjan Marion via lists.fd.io]

> On 24.05.2022., at 14:28, PRANAB DAS  wrote:
> 
> Hi Damjan,
> 
> The snort plugin could be simple. But I am not familiar with VPP 
> memory/buffer management as such and I am finding it not so easy to navigate. 
> And looking at the physmem.c/h code, it appears the VPP uses heap memory 
> (mmap) and has its own heap/buffer management system.

VPP uses mmap system call (same like DPDK) to map shared memory, but that is 
not heap memory.

VPP buffer memory is shared memory (typically hugepage backed). There is one 
block of shared memory per NUMA, and each block have own FD.
VPP can pass that FD to remote app over UDS and remote app can simply map that 
shared memory, Both memif and snort plugins do exactly that.

Main complexity is creating another shared memory region which holds enqueue 
and dequeue rings: In snort plugin you can see how that shared memory is 
orgaised by looking at src/plugins/snort/daq_vpp.h


> Could you clarify? And in the snort plugin exposes/shares the mmap memory 
> region to the external program (snort). Is there any documentation that 
> provides an overview of VPP buffer management and how VPP memory/buffers can 
> be shared with external trusted applications?

No, unfortunately there is no documentation, but there is running code (snort 
plugin) which does exactly that.
If you have any questions, ask here and i will try to help.

> 
> Thank you
> 
> - PK Das
>  
> 
> 
> 
> On Tue, May 24, 2022 at 7:51 AM Damjan Marion  > wrote:
> 
> VPP is not DPDK application, VPP features doesnt maintain DPDK metadata, in 
> many cases we use native drivers so DPDK is not even loaded so you cannot use 
> rte_ring unless you want to write complete translation layer which will 
> likely be significantly slower that using native way which snort plugin uses.
> 
> Why do you think zero copy interface in snort plugin is not simple?
> 
> — 
> Damjan
> 
>> On 24.05.2022., at 13:34, PRANAB DAS > > wrote:
>> 
>> 
>> Thank you very much for your response Benoit!
>> I am wondering if there is another option e.g. rte-ring of DPDK or if that 
>> option is not feasible in VPP? 
>> Could you comment? We are looking for a service-chaining application similar 
>> to snort but would like to have a much simpler zero-copy interface.
>> 
>> Thank you,
>> 
>> - P K DAS
>> 
>> On Tue, May 24, 2022 at 4:22 AM Benoit Ganne (bganne) > > wrote:
>> It all depends on what you want to do. Usually, we try to avoid sharing 
>> buffers read/write between multiple process, it makes debugging much harder 
>> - especially buffer leaks or use-after-free...
>> Here is an example to share VPP buffers read-only with snort so that snort 
>> can inspect traffic and gives a verdict back without any copy: 
>> https://git.fd.io/vpp/tree/src/plugins/snort 
>> 
>> 
>> Best
>> ben
>> 
>> > -Original Message-
>> > From: vpp-dev@lists.fd.io  
>> > mailto:vpp-dev@lists.fd.io>> On Behalf Of PRANAB DAS
>> > Sent: Monday, May 23, 2022 20:11
>> > To: vpp-dev@lists.fd.io 
>> > Subject: Re: [vpp-dev] zero memcpy interface (alternative to memif) to
>> > pass packets from VPP to another trusted DPDK application
>> > 
>> > Hi
>> > 
>> > Could some one comment on zero-copy alternative to memif interface? Any
>> > ideas, comments are welcome.
>> > 
>> > Thank you
>> > 
>> > - Pranab K Das
>> 
>> 
>> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21442): https://lists.fd.io/g/vpp-dev/message/21442
Mute This Topic: https://lists.fd.io/mt/91252298/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] zero memcpy interface (alternative to memif) to pass packets from VPP to another trusted DPDK application

[PRANAB DAS]

Hi Damjan,

The snort plugin could be simple. But I am not familiar with VPP
memory/buffer management as such and I am finding it not so easy to
navigate.
And looking at the physmem.c/h code, it appears the VPP uses heap memory
(mmap) and has its own heap/buffer management system. Could you clarify?
And in the snort plugin exposes/shares the mmap memory region to the
external program (snort). Is there any documentation that provides an
overview of VPP buffer management and how VPP memory/buffers can be shared
with external trusted applications?

Thank you

- PK Das




On Tue, May 24, 2022 at 7:51 AM Damjan Marion  wrote:

>
> VPP is not DPDK application, VPP features doesnt maintain DPDK metadata,
> in many cases we use native drivers so DPDK is not even loaded so you
> cannot use rte_ring unless you want to write complete translation layer
> which will likely be significantly slower that using native way which snort
> plugin uses.
>
> Why do you think zero copy interface in snort plugin is not simple?
>
> —
> Damjan
>
> On 24.05.2022., at 13:34, PRANAB DAS  wrote:
>
> 
> Thank you very much for your response Benoit!
> I am wondering if there is another option e.g. rte-ring of DPDK or if that
> option is not feasible in VPP?
> Could you comment? We are looking for a service-chaining application
> similar to snort but would like to have a much simpler zero-copy interface.
>
> Thank you,
>
> - P K DAS
>
> On Tue, May 24, 2022 at 4:22 AM Benoit Ganne (bganne) 
> wrote:
>
>> It all depends on what you want to do. Usually, we try to avoid sharing
>> buffers read/write between multiple process, it makes debugging much harder
>> - especially buffer leaks or use-after-free...
>> Here is an example to share VPP buffers read-only with snort so that
>> snort can inspect traffic and gives a verdict back without any copy:
>> https://git.fd.io/vpp/tree/src/plugins/snort
>>
>> Best
>> ben
>>
>> > -Original Message-
>> > From: vpp-dev@lists.fd.io  On Behalf Of PRANAB DAS
>> > Sent: Monday, May 23, 2022 20:11
>> > To: vpp-dev@lists.fd.io
>> > Subject: Re: [vpp-dev] zero memcpy interface (alternative to memif) to
>> > pass packets from VPP to another trusted DPDK application
>> >
>> > Hi
>> >
>> > Could some one comment on zero-copy alternative to memif interface? Any
>> > ideas, comments are welcome.
>> >
>> > Thank you
>> >
>> > - Pranab K Das
>>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21441): https://lists.fd.io/g/vpp-dev/message/21441
Mute This Topic: https://lists.fd.io/mt/91252298/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] zero memcpy interface (alternative to memif) to pass packets from VPP to another trusted DPDK application

[Damjan Marion via lists.fd.io]

VPP is not DPDK application, VPP features doesnt maintain DPDK metadata, in 
many cases we use native drivers so DPDK is not even loaded so you cannot use 
rte_ring unless you want to write complete translation layer which will likely 
be significantly slower that using native way which snort plugin uses.

Why do you think zero copy interface in snort plugin is not simple?

— 
Damjan

> On 24.05.2022., at 13:34, PRANAB DAS  wrote:
> 
> 
> Thank you very much for your response Benoit!
> I am wondering if there is another option e.g. rte-ring of DPDK or if that 
> option is not feasible in VPP? 
> Could you comment? We are looking for a service-chaining application similar 
> to snort but would like to have a much simpler zero-copy interface.
> 
> Thank you,
> 
> - P K DAS
> 
>> On Tue, May 24, 2022 at 4:22 AM Benoit Ganne (bganne)  
>> wrote:
>> It all depends on what you want to do. Usually, we try to avoid sharing 
>> buffers read/write between multiple process, it makes debugging much harder 
>> - especially buffer leaks or use-after-free...
>> Here is an example to share VPP buffers read-only with snort so that snort 
>> can inspect traffic and gives a verdict back without any copy: 
>> https://git.fd.io/vpp/tree/src/plugins/snort
>> 
>> Best
>> ben
>> 
>> > -Original Message-
>> > From: vpp-dev@lists.fd.io  On Behalf Of PRANAB DAS
>> > Sent: Monday, May 23, 2022 20:11
>> > To: vpp-dev@lists.fd.io
>> > Subject: Re: [vpp-dev] zero memcpy interface (alternative to memif) to
>> > pass packets from VPP to another trusted DPDK application
>> > 
>> > Hi
>> > 
>> > Could some one comment on zero-copy alternative to memif interface? Any
>> > ideas, comments are welcome.
>> > 
>> > Thank you
>> > 
>> > - Pranab K Das
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21440): https://lists.fd.io/g/vpp-dev/message/21440
Mute This Topic: https://lists.fd.io/mt/91252298/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP call topic - csit.fd.io perf dashboard preview

[Maciek Konstantynowicz (mkonstan) via lists.fd.io]

Hi Damjan,

For the VPP call today, if possible, could we get 10-15min for
CSIT team to do a demo of the new csit.fd.io perf dashboard?

Cheers,
Maciek

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21439): https://lists.fd.io/g/vpp-dev/message/21439
Mute This Topic: https://lists.fd.io/mt/91309098/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] zero memcpy interface (alternative to memif) to pass packets from VPP to another trusted DPDK application

[PRANAB DAS]

Thank you very much for your response Benoit!
I am wondering if there is another option e.g. rte-ring of DPDK or if that
option is not feasible in VPP?
Could you comment? We are looking for a service-chaining application
similar to snort but would like to have a much simpler zero-copy interface.

Thank you,

- P K DAS

On Tue, May 24, 2022 at 4:22 AM Benoit Ganne (bganne) 
wrote:

> It all depends on what you want to do. Usually, we try to avoid sharing
> buffers read/write between multiple process, it makes debugging much harder
> - especially buffer leaks or use-after-free...
> Here is an example to share VPP buffers read-only with snort so that snort
> can inspect traffic and gives a verdict back without any copy:
> https://git.fd.io/vpp/tree/src/plugins/snort
>
> Best
> ben
>
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of PRANAB DAS
> > Sent: Monday, May 23, 2022 20:11
> > To: vpp-dev@lists.fd.io
> > Subject: Re: [vpp-dev] zero memcpy interface (alternative to memif) to
> > pass packets from VPP to another trusted DPDK application
> >
> > Hi
> >
> > Could some one comment on zero-copy alternative to memif interface? Any
> > ideas, comments are welcome.
> >
> > Thank you
> >
> > - Pranab K Das
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21438): https://lists.fd.io/g/vpp-dev/message/21438
Mute This Topic: https://lists.fd.io/mt/91252298/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Question about vpp neighbour Mac entry

[Benoit Ganne (bganne) via lists.fd.io]

That's not how a layer 3 network works: the dest mac is the mac address of the 
L3 nexthop.
If you want to use the dest mac of the switch as nexthop, it should act as a 
router (with an IP address you can use as nexthop).

Best
Ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Atul Sharma
> Sent: Friday, May 20, 2022 15:28
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Question about vpp neighbour Mac entry
> 
> Hello VPP experts,
> 
> I have a question about the behaviour of vpp neighbour Mac entry. In
> particular, I am noticing the node(ipv4-glean) is dropping the original
> packet that triggers glean process.
> I know the Mac address of switch so I'm adding the switch Mac as next hop
> of the packet but still packet goes to glean and packet destination
> address added as neighbour.
> I don't want to drop the packet. Instead It should go to next hop(switch).
> Why this behaviour did I miss something.
> I'm Using VPP 21.06.
> 
> 
> Regards,
> Atul Sharma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21437): https://lists.fd.io/g/vpp-dev/message/21437
Mute This Topic: https://lists.fd.io/mt/91230759/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Help needed in bringing up memif with shm_open.

[Benoit Ganne (bganne) via lists.fd.io]

I think you should run step-by-step with gdb to see exactly what is failing. As 
it works on a recent system but not on an old one, I suspect an issue with an 
unsupported feature (eg. special flag in syscall or similar)...

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Pragya Nand
> Bhagat
> Sent: Saturday, May 21, 2022 15:30
> To: pragya.nand.bhaga...@gmail.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Help needed in bringing up memif with shm_open.
> 
> Hi,
> 
> I'm able to send and receive packet when I compile with gcc version
> (Ubuntu 8.4.0-1ubuntu1~18.04) , GLIBC 2.27 and kernel 5.4.0-66-lowlatency.
> but when I compile with gcc gcc (GCC) 5.4.0, GLIBC 2.17 , and kernel
> 3.10.0-rt56 it fails at memif_buffer_alloc.
> Any idea why this behaviour can be .
> 
> Thanks for all the suggestions and insights.
> 
> Thank You
> Pragya Nand
> 
> On Fri, May 20, 2022 at 10:26 AM Pragya Nand Bhagat via lists.fd.io
>     > wrote:
> 
> 
>   Hi All,
> 
>   I'm trying to connect two existing container application by using
> memif.
>   Unfortunately these are old codes and i'm stuck with old glibc and
> kernel .
>   So I'm trying to use shm_open instead of memfd_create .
> 
>   The issue that I'm facing is are as follows :
> 
>   It throws following error while trying to do tx :
>   memif_tx_burst : Invalid argument. (This comes from src/main.c 1746
> - 1750)
>   When I try to do a rx I get the interrupt but the received packet
> is 0.
>   It would be a great help if someone knows changes which are
> required for libmemif to work with shm_open.
> 
>   I'm working on same and will share changes if it works.
> 
>   Thank You
>   Pragya Nand Bhagat
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21435): https://lists.fd.io/g/vpp-dev/message/21435
Mute This Topic: https://lists.fd.io/mt/91224655/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] handling L2 and L3 traffic in gtpu plugin

[Stanislav Zaikin]

Hi Vijay,

You can adopt something similar to what was implemented for vxlan. Like
specifying the next-node for the tunnel when creating.

On Tue, 24 May 2022 at 07:52,  wrote:

> Hi,
>
> I wants to understand, how can i handle L2 and L3 traffic in gtpu plugin
> during encap and decap.
> Do anyone have any idea? How can this be handled.
>
> Regards,
> Vijay
> 
>
>

-- 
Best regards
Stanislav Zaikin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21434): https://lists.fd.io/g/vpp-dev/message/21434
Mute This Topic: https://lists.fd.io/mt/91305840/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-