[RFE] Mirror VF Ports

if you have any idea how to implement it, can you share?

Can you please provide some more details about what mirroring ports means in this context?

What is it that the user wants to do in this case that they can't do now?

Whoops, I didn't notice this is in the tap as a service context. This request makes sense.

Since this is for tap-as-a-service which isn't under Neutron governance ATM you don't need drivers team approval for this one, just approval from TaaS folks.

@YAMAMOTO, In the event there is a port that is from sr-iov, we will be calling VFd to setup mirroring. This probably only works if the source and destination are sr-iov ports, not sure about mixing them. VFd is apart of DPDK.

If you abide by the TaaS API they're not guaranteed to even be on the same host.

@ian that may be possible depending on your choice of nic.
niantic an fortvile dont support this today if the forwarding mechanisum is l3 based
but it should be possible to use the flow director apis via the vfd to do mac based forwarding
to another host e.g. rewrited mac to remote back and tx to phyical networks assuming they are on the same l2 segment.

other vendors nics if they can supprot vxlan or other l3 protocol encap may be able to support the
full richness of the TaaS API but i have to admit i am not versed in what it enables our our competitors product stacks enough to know what the constraints are.

with nics getting smarter future nics could supprot more of the api but in the interim it would also be posibly to use flow director in the nic to mirror the traffic to a speficis queue on the pf that would be read by the vfd which would internally forward the packet as requested by the TaaS api.
the VFD is runing as a dpdk primary application and contols the phyical function via a dpdk PDM so while currently id dose not preform traffic forwording it could if it chose to do so in this case to facilitate inter host tap as a service fuctionality.

In this instance, SRIOV mirroring would want to spit the packets out of the net link in at least the worst case scenario - and this isn't a simple MAC rewrite, because you want the MAC in the information, it has to be an encap. If that requires a duplication to a DPDK service that does the encap then that would meet the requirements, though the uncosted extra load on the host and the limited-capacity DMA interface would be a concern.

https://review.openstack.org/#/c/574477/