netdev - RE: [PATCH 0/1] net-next: Port Mirroring support for SR-IOV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BY5PR12MB43223DDB8011260DD65B9405DC239@BY5PR12MB4322.namprd12.prod.outlook.com>
Date:   Thu, 27 May 2021 13:06:35 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Karthik S <ksundara@...hat.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "karthik.sundaravel@...il.com" <karthik.sundaravel@...il.com>,
        Christophe Fontaine <cfontain@...hat.com>,
        Veda Barrenkala <vbarrenk@...hat.com>,
        Vijay Chundury <vchundur@...hat.com>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: RE: [PATCH 0/1] net-next: Port Mirroring support for SR-IOV


> From: Karthik S <ksundara@...hat.com>
> Sent: Thursday, May 27, 2021 4:03 PM
> 
> The purpose of this message is to gather feedback from the Netdev
> community on the addition of SRIOV port mirroring to the iproute2 ip CLI.

> iproute2 was chosen as the desired interface because there is already
> extensive support for SRIOV configuration built in and many Linux users are
> familiar with it for configuring Network functionality in the driver thus port
> mirroring naturally fits into this schema.
> 
> Port mirroring involves sending a copy of packets entering and/or leaving one
> port to another port which is usually different from the original destination
> of the packets being mirrored.Hardware Port Mirroring can provide the
> following benefits for users:
> 1) Live debugging of network issues without bringing any interface or
> connection down
> 2) No latency addition when port mirroring tap is introduced
> 3) No extra CPU resources are required to perform this function
> 
> The prospective implementation would provide three modes of packet
> mirroring (For Egress or Ingress):
> 1) PF to VF
> 2) VF to VF
> 3) VLAN to VF
> 
> The suggested iproute2 ip link interface for setting up Port Mirroring is as
> follows:

ip link vf set commands are for legacy sriov implementation to my knowledge.
It is not usable for below 4 cases.
1. switchdev sriov devices
2. pci subfunctions switchdev devices
3. smartnic where VFs and eswitch are on different PCI device.
4. PCI PF on the smartnic managed via same switchdev cannot be mirrored.

With the rich switchdev framework via PF,VF, SF representors, tc seems to be right approach to me.

Such as, 
$ tc filter add dev vf1_rep_eth0 parent ffff: \
	protocol ip u32 match ip protocol 1 0xff \
	action mirred egress mirror dev vf2_rep_eth1

Few advantages of tc I see are:
1. It overcomes limitations of all above #4 use cases

2. tc gives the ability to mirror specific traffic based on match criteria instead of proposed _all_vf_ traffic
This is useful at high throughput VFs where filter itself helps to mirror specific packets.
At the same time matchall criteria also works like the proposed API.

I do not know the netdev direction for non switchdev (legacy) sriov nics.