RE: [virtio] RE: [virtio-comment] [PATCH requirements 5/7] net-features: Add n-tuple receive flow steering requirements

[Parav Pandit <parav@nvidia.com>]

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Tuesday, June 6, 2023 8:09 AM

> 
> We have already aligned the requirements internally. There is a common
> requirement in the cloud scenario: a virtual nic with SR-IOV capability.
> The user of a vm splits it into one PF + multiple VFs, and each VF takes some of
> the queues from the PF. Each VF can get its own IP address and mac from the PF.
> 
> However, the forwarding component (here it can be understood as an eswitch)
> connected to the virtual nic cannot see VFs, but can only see the PF (when
> creating the SR-IOV virtual nic, the PF is bound to a forwarding component).
> This behavior does not affect users (such as users in containers) using the VF,
> that is, the user sees a real virtual nic. However, the data incoming and outgoing
> this VF nic needs to be distinguished in the forwarding component:
> 
> 1. When the packet comes out of the VF nic (from the perspective of the
> forwarding component, it comes out of a queue of the PF), the source ip of the
> packet is still the ip of the VF, and the forwarding component forwards it
> directly;
> 
> 2. When packets arrive at the forwarding component, the IPs seen by the
> forwarding component (the IPs of all VFs) are the IPs of the PF.
> If the forwarding component wants to direct packets to the corresponding VF, it
> should use the flow director rules with the VF id issued by the PF.
>
> Perhaps the admin queue can achieve this capability, but the flow director rule
> carrying the VF id has become the ethtool and kernel standard, 
To my knowledge the eswitch model is not part of the ethtool.
It is part of the tc flower offloads and it covers far more than just _forwarding_ rules.

so we should be able to steer to a vf_id with a abstraction of say switch_port_id as far as spec is concerned.

The main difference is the type of rules eswitch vs the guest driver adds are very different.
But yes, both should be able to use some of the common infrastructure.

We should consider this requirement in mind and craft the "destination" to cover this.

Since the flow insertion/removal queue should be present in one case PF and other case on VFs, we likely need a different queue than the AQ or expand the scope.

We should cover these in the design/requirements further.

I will update this details in the v1.

> so we can try to
> include it in the flow director's ability first (this means that the flow director
> itself can have this behavior, especially for those PFs that intend to limit the
> capabilities of the VF, and this behavior can effectively support our scenario).