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]
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ