[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [virtio-comment] Re: [PATCH v12] virtio-net: support inner header hash
å 2023/4/14 äå12:08, Parav Pandit åé:
From: Heng Qi <hengqi@linux.alibaba.com> Sent: Friday, April 14, 2023 12:01 AM å 2023/4/14 äå11:10, Jason Wang åé:On Fri, Apr 14, 2023 at 5:46âAM Michael S. Tsirkin <mst@redhat.com> wrote:On Thu, Apr 13, 2023 at 07:03:26PM +0800, Heng Qi wrote:For example, when the packets of certain +tunnels are spread across multiple receive queues, these receive queues may have an unbalanced +amount of packets. This can cause a specific receive queue to become full, resulting in packet loss.We have many places that can lead to packet dropping. For example, the automatic steering is best effort. I tend to avoid mentioning things like this.Ok. And Michael what do you think about this?I think this text did not do a great job explaining the security aspect. Here's a better, shorter explanation: It is often an expectation of users that a tunnel isolates the external network from the internal one. By completely ignoring entropy in the external header and replacing it with entropy from the internal header, for hash calculations, this expectation might be violated to a certain extent, depending on how the hash is used. When the hash use islimitedto RSS queue selection, the effect will likely be limited to ability of users inside the tunnel to cause packet drops in multiple queues (as opposed to a single queue without the feature).And this is only for GRE-in-UDP? This makes me think if we should add GRE support for the outer header like: https://docs.napatech.com/r/Feature-Set-N-ANL9/Hash-Key-Type-10-3-Tupl e-GREv0I think this is for tunneling protocols with specific flow fields, such as GRE:key filed, NVGRE:FLOWID filed. This requires us to make a requirement when calculating the hash of the tunnels when F_TUNNEL_HASH is not negotiated. It's a new work.Yes, I think Jason is saying the same to extend the outer header hashing for newer protocols where outer header entropy is available.
I see:), and then we need a new feature bit to do this, which can enter the scheduling, but we have to consider the rest of our scheduling, for example, I will first start with symmetric toeplitz hash/xor hash, and then here to things. In addition, what I want to say is that we are also planning to do (1) time synchronization between drivers and devices (2) assist colleagues in doing hw rx timestamp, etc.
Thanks.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]