Re: [PATCH v10] virtio-net: support inner header hash

[Parav Pandit <parav@nvidia.com>]

On 3/15/2023 9:19 AM, Heng Qi wrote:
> å 2023/3/15 äå11:23, Parav Pandit åé:
> > On 3/6/2023 10:48 AM, Heng Qi wrote:
[..]
> > > Â \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > > +\item[VIRTIO_NET_F_HASH_TUNNEL] Requires VIRTIO_NET_F_CTRL_VQ.
> > I think this should also say that HASH_TUNNEL requires either of the 
> > F_RSS or F_HASH_REPORT.
> > Because without it HASH_TUNNEL is not useful.
>
> F_HASH_TUNNEL indicates that the hash should be calculated using the 
> inner packet header, even without F_RSS or F_HASH_REPORT,
> we can continue to use the hash value in scenarios such as RPS or ebpf 
> programs.
Yes.
Even for rps or ebpf programs, F_HASH_TUNNEL is fine.
When such feature arrives in future, it above line will have OR 
condition for RPS feature bit.

> I think it's fine to let F_HASH_TUNNEL rely on F_RSS or _F_HASH_REPORT 
> as those are probably important scenarios where inner packet header hash 
> is used.
Yes.

> > If not, for now it may be better to skip vxlan and nvegre as they 
> > inherently have unique outer header UDP src port based on the inner 
> > header.
>
> Symmetric hashing ignores the order of the five-tuples when calculating 
> the hash, that is, using (a1,a2,p1,p2) and (a2,a1,p2,p1) respectively 
> can calculate the same hash.
> There is a scenario that the two directions client1->client2 and 
> client2->client1 of the same flow may pass through different tunnels.
> In order to allow the data in two directions to be processed by the same 
> CPU, we need to calculate a symmetric hash based on the inner packet 
> header.
I am lost in two directions and two clients above.
When you say two directions, do you mean tx and rx?
and do symmetric hashing between tx and rx between two end points within 
single tunnel?

> > > +\field{hash_tunnel_types} is set to VIRTIO_NET_HASH_TUNNEL_TYPE_NONE 
> > > by the device for the
> > > +unencapsulated packets.
> > > +
I missed this before. unencapsulated is not a term.
s/unencapsulated packets/Non encapsulated packets or non tunneled packets