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]

Date:   Mon, 31 May 2021 13:12:04 +0530
From:   Karthik Sundaravel <ksundara@...hat.com>
To:     Parav Pandit <parav@...dia.com>
Cc:     "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

On Thu, May 27, 2021 at 6:36 PM Parav Pandit <parav@...dia.com> wrote:
>
>
> > 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.

1. While iproute and switchdev may be similar in their actions for
port mirroring, they both have unique use-cases for it, switchdev uses
it for flow replication and iproute uses it for port/device tracking.
2. Also some legacy devices do not support switchdev, and iproute
provides a means of a port mirroring solution that covers a wide range
of Network Interface Controllers out there today.