Mike Pattrick <[email protected]> writes:
> On Tue, Mar 4, 2025 at 10:51 AM Aaron Conole <[email protected]> wrote:
>>
>> Jun Wang via discuss <[email protected]> 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).
> -M
>
>>
>> >> What do you think?
>> >> M
>> >>
>> >> On Mon, Feb 24, 2025 at 2:25 AM Jun Wang via discuss
>> >> <[email protected]> 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
>> >>> [email protected]
>> >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>> >
>> > -------------------------------------------------------------------------------------------------------------------------
>> > Jun Wang
>> >
>> > _______________________________________________
>> > discuss mailing list
>> > [email protected]
>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
