RE: [virtio-comment] [PATCH v8] virtio-net: support inner header hash

[Parav Pandit <parav@nvidia.com>]

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Monday, February 13, 2023 8:05 AM
> Hi, all.
> 
> Do you have any comments on this version?
> 
> Thanks.
> 
> 在 2023/2/8 下午5:08, Heng Qi 写道:
> > If the tunnel is used to encapsulate the packets, the hash calculated
> > using the outer header of the receive packets is always fixed for the
> > same flow packets, i.e. they will be steered to the same receive queue.
> >
> > We add a feature bit VIRTIO_NET_F_HASH_TUNNEL and related bitmasks in
> > \field{hash_tunnel_types}, which instructs the device to calculate the
> > hash using the inner headers of tunnel-encapsulated packets. Besides,
> > values in \field{hash_report_tunnel_types} are added to report tunnel types.
> >
> > Note that VIRTIO_NET_F_HASH_TUNNEL only indicates the ability of the
> > inner header hash, and does not give the device the ability to use the
> > hash value to select a receiving queue to place the packet.
> >
[..]
> > @@ -3384,9 +3396,10 @@ \subsection{Device Operation}\label{sec:Device
> Types / Network Device / Device O
> >           le16 csum_start;
> >           le16 csum_offset;
> >           le16 num_buffers;
> > -        le32 hash_value;        (Only if VIRTIO_NET_F_HASH_REPORT
> negotiated)
> > -        le16 hash_report;       (Only if VIRTIO_NET_F_HASH_REPORT
> negotiated)
> > -        le16 padding_reserved;  (Only if VIRTIO_NET_F_HASH_REPORT
> negotiated)
> > +        le32 hash_value;              (Only if VIRTIO_NET_F_HASH_REPORT
> negotiated)
> > +        le16 hash_report;             (Only if VIRTIO_NET_F_HASH_REPORT
> negotiated)
> > +        u8 hash_report_tunnel_types;  (Only if VIRTIO_NET_F_HASH_REPORT

I am yet to review the changes of v8.
But the quick response is, I do not see a use case of above field by sw driver.
And this addition requires the core hw data path to supply this value.
Without good motivation, it is hard to have it here.

What is valuable is to have a VNI already identified and coming to the driver, like a hash value.
This can cut down the cpu processing power, in outer header packet processing.
However, that is relatively a different feature than inner hash.

So, my input is to omit hash_report_tunnel_types.
Will respond to Michael question in other thread.