>Mike Pattrick <m...@redhat.com> writes:
>
>> On Tue, Mar 4, 2025 at 10:51 AM Aaron Conole <acon...@redhat.com> wrote:
>>>
>>> Jun Wang via discuss <ovs-discuss@openvswitch.org> writes:
>>>
>>> >> Hello,
>>> >
>>> >> Yes, this will result in better ovs-tcpdump performance. The reason
>>> >> why it hasn't been added so far is because we can't guarantee or even
>>> >> check for the existence of any given DPDK driver at runtime in a
>>> >> generic fashion.
>>> >>
>>> >> One option would be to select this type of interface with a
>>> >> non-default command line flag.
>>> >
>>> > Hi, I also believe that choosing a non-default command line flag
>>> > to support this is a good option, allowing customers to decide
>>> > whether or not
>>> > to use this flag.
>>> > However, there are still some details to consider, such as whether to
>>> > allow users to configure the virtio-user port queue,
>>> > and whether virtio-user usage requires affinity configuration, etc.
>>>
>>> ovs-tcpdump will already support using `--mirror-to` as a destination.
>>> Wouldn't that be an appropriate flag? There's a lot involved with setup
>>> for a successful DPDK environment, and as you note lots of user required
>>> input.
>>
>> Unfortunately, mirror-to only lets you set the interface name. It will
>> still try to create a tap device and add it to OVS. If the interface
>> already exists, ovs-tcpdump will quit with an error.
>
>Hrrm... I thought it shouldn't:
>
> if sys.platform in _make_taps and \
> mirror_interface not in interfaces():
> _make_taps[sys.platform](mirror_interface,
> ovsdb.interface_mtu(interface))
> tap_created = True
> else:
> tap_created = False
>
>But I guess interfaces() might not match because the DPDK devices won't
>appear in /dev/net (or likely be dumped from netifaces function).
>
>Maybe the fix there could be to make mirror-to aware of these other
>devices (for instance, maybe searching the interfaces in OVSDB).
Yes, I have actually tried using mirror-to, and it does result in an error.
The error message and the corresponding code are as follows:
[root@compute0-dpdk /]# ovs-tcpdump -i vh-userclient-e5281ddf-c8 --mirror-to
veth1
ERROR: Mirror port (veth1) exists for port vh-userclient-e5281ddf-c8.
if ovsdb.port_exists(mirror_interface):
print("ERROR: Mirror port (%s) exists for port %s." %
(mirror_interface, interface))
sys.exit(1)
>> -M
>>
>>>
>>> >> What do you think?
>>> >> M
>>> >>
>>> >> On Mon, Feb 24, 2025 at 2:25 AM Jun Wang via discuss
>>> >> <ovs-discuss@openvswitch.org> wrote:
>>> >>>
>>> >>> Hi,team.
>>> >>> In OVS-DPDK scenarios, using ovs-tcpdump for packet capture
>>> >>> can significantly impact forwarding performance due to the
>>> >>> packet
>>> > processing between user space and kernel space.
>>> >>> This impact is especially noticeable when there is high traffic
>>> >>> or when multiple capture ports are started, causing the
>>> >>> performance to
>>> > degrade drastically.
>>> >>> Therefore, the question is whether we have considered improving
>>> >>> the packet capture capability of ovs-tcpdump in OVS-DPDK
>>> >>> scenarios.
>>> > Based on my analysis,
>>> >>> I believe replacing the default ovs-tcpdump mirror port with the
>>> >>> DPDK virtio-user interface would greatly enhance processing
>>> >>> performance.
>>> >>>
>>> >>> https://doc.dpdk.org/guides-24.11/howto/virtio_user_as_exception_path.html
>>> >>>
>>> >>> Command to create a virtio-user port on an OVS-DPDK bridge：
>>> >>>
>>> >>> ovs-vsctl --may-exist add-port br-tun veth1 -- set interface veth1
>>> >>> type=dpdk -- set interface veth1
>>> > options:dpdk-devargs="vdev:virtio_user0,path=/dev/vhost-net,iface=veth1"
>>> >>>
>>> >>> After creation, the corresponding interface veth1 is bound to PMD：
>>> >>> [root@compute0-dpdk /]# ovs-appctl dpif-netdev/pmd-rxq-show
>>> >>> pmd thread numa_id 1 core_id 21:
>>> >>> isolated : false
>>> >>> port: tun_port_p0 queue-id: 0 (enabled) pmd usage: 0 %
>>> >>> port: vh-userclient-e5281ddf-c8 queue-id: 0 (enabled) pmd usage:
>>> >>> 0 %
>>> >>> overhead: 0 %
>>> >>> pmd thread numa_id 1 core_id 22:
>>> >>> isolated : false
>>> >>> port: tun_port_p0 queue-id: 1 (enabled) pmd usage: 0 %
>>> >>> port: veth1 queue-id: 0 (enabled) pmd usage: 0 %
>>> >>> overhead: 0 %
>>> >>> pmd thread numa_id 1 core_id 23:
>>> >>> isolated : false
>>> >>> port: tun_port_p1 queue-id: 0 (enabled) pmd usage: 0 %
>>> >>> overhead: 0 %
>>> >>> pmd thread numa_id 1 core_id 24:
>>> >>> isolated : false
>>> >>> port: tun_port_p1 queue-id: 1 (enabled) pmd usage: 0 %
>>> >>> overhead: 0 %
>>> >>>
>>> >>> And the corresponding veth1 kernel interface can be seen in the kernel：
>>> >>> [root@compute0-dpdk /]# ip ad|grep veth1
>>> >>> 700: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
>>> >>> default qlen 1000
>>> >>>
>>> >>> So, we only need to redirect the mirrored traffic to the
>>> >>> virtio-user port, which significantly improves performance
>>> >>> compared to the default
>>> > kernel-space mirror port.
>>> >>>
>>> >>> ________________________________
>>> >>> Jun Wang
>>> >>> _______________________________________________
>>> >>> discuss mailing list
>>> >>> disc...@openvswitch.org
>>> >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>> >
>>> > -------------------------------------------------------------------------------------------------------------------------
>>> > Jun Wang
>>> >
>>> > _______________________________________________
>>> > discuss mailing list
>>> > disc...@openvswitch.org
>>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>>
Jun Wang
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
