[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH v8] virtio-net: support inner header hash
On Mon, Feb 13, 2023 at 09:42:25PM +0000, Parav Pandit wrote: > > > > 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. I think I agree that we should be careful about adding stuff in packet header. Yes it's using the padding but we only have 2 bytes of that. > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]