RE: [virtio-dev] Re: [virtio-comment] Re: [PATCH v12] virtio-net: support inner header hash

[Parav Pandit <parav@nvidia.com>]

> 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.