[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
> 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 is > limited > >> to 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-GREv0 > > I 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]