[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] RE: [virtio-comment] [PATCH v8] virtio-net: support inner header hash
å 2023/2/14 äå5:42, Parav Pandit åé:
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:DeviceTypes / Network Device / Device Ole16 csum_start; le16 csum_offset; le16 num_buffers; - le32 hash_value; (Only if VIRTIO_NET_F_HASH_REPORTnegotiated)- le16 hash_report; (Only if VIRTIO_NET_F_HASH_REPORTnegotiated)- le16 padding_reserved; (Only if VIRTIO_NET_F_HASH_REPORTnegotiated)+ le32 hash_value; (Only if VIRTIO_NET_F_HASH_REPORTnegotiated)+ le16 hash_report; (Only if VIRTIO_NET_F_HASH_REPORTnegotiated)+ u8 hash_report_tunnel_types; (Only if VIRTIO_NET_F_HASH_REPORTI 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'm really okay with this, the tunnel type seems to help the software driver do more things in the future, for example, the driver may not want to use the outer hash value when forwarding packets. But if there is really no practical scenario for the driver at present, then let us hide the tunnel types in the \field{hash_report}?
What is valuable is to have a VNI already identified and coming to the driver, like a hash value.
This is too specific to a certain tunnel protocol, not every protocol has corresponding VNI information.
Thanks.
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. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]