| Message ID | 20210527103318.801175-1-ksundara@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net-next: Port Mirroring support for SR-IOV | expand |
> From: Karthik S <ksundara@redhat.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.
On Thu, May 27, 2021 at 6:36 PM Parav Pandit <parav@nvidia.com> wrote: > > > > From: Karthik S <ksundara@redhat.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.
On Mon, 31 May 2021 13:12:04 +0530 Karthik Sundaravel wrote: > 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. Hard no on extending legacy SR-IOV API.
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 set dev <pf> vf <dest_vfid> mirror [ add [ vf src_vfids [ dir { in | out | all } ] ] | [ pf [ dir { in | out | all } ] ] | [ vlan vlan_ids ] [ del [ vf src_vfids [ dir { in | out | all } ] ] | [ pf [ dir { in | out | all } ] ] | [ vlan vlan_ids ] [ set [ vf src_vfids [ dir { in | out | all } ] ] | [ pf [ dir { in | out | all } ] ] | [ vlan vlan_ids ] [ clear ] $ip link show <pf> Whilst significant resources have already gone into an internal PoC for this feature, this request for feedback is being done to make sure this solution is acceptable to the Netdev community before further resources are committed for an eventual RFC Patch. Kernel Changes: https://github.com/karthiksundaravel/linux Example driver: https://github.com/karthiksundaravel/i40e-2.12.6 Iproute changes: https://github.com/veda10/iproute2 Karthik S (1): rtnetlink: Port mirroring support for SR-IOV include/linux/netdevice.h | 4 ++ include/uapi/linux/if_link.h | 46 +++++++++++++ net/core/rtnetlink.c | 123 ++++++++++++++++++++++++++++++++++- 3 files changed, 172 insertions(+), 1 deletion(-)