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

[Heng Qi <hengqi@linux.alibaba.com>]

On Tue, Jun 06, 2023 at 09:49:28PM +0000, Parav Pandit wrote:
> 
> 
> > 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.
> 

Please refer to the kernel function ethtool_get_flow_spec_ring_vf() and
"ethtool -h | grep -E 'vf|queue'" of the Ethtool tool (I'm not saying we
have to rely on ethtool, but it's at least one of the useful and
standard tools).

On the PF side, the user can see the VFs. For example, there is VF1 with
IP 1.2.3.4, we just want PF to issue something like

"ethtool -N PF flow-type udp dst-ip 1.2.3.4 VF1",

and then the device receives such a command/rule (the device does
not see the VF, but it can convert the VF id to the corresponding queues,
and then send the packets to these queues or one queue). This is what
we need, just a VF id, nothing else.

Of course, we could use a more generic field.

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

Yes.

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

Yes, we can make this included in the "destination".

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

Ok, thanks a lot!

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