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 10:40 PM

> 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",
>
This is probably ancient and probably for a single vendor who could not implement full eswitch.
I may be incomplete/wrong here.

But for 100% sure that Linux kernel eswitch model is through the representors.
I have built and extended the represnetors for VF, PF, SF, with and without DPU modes and lot of plumbing of it with devlink.
And all uniformly connected to netdev representors.

So I don't think ethtool VF1 patch will be accepted upstream stream.
May be I am wrong.

But for sure, if we build eswitch for virtio net for Linux, it should be through the tc manner.
 
> 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).
> >