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

[Heng Qi <hengqi@linux.alibaba.com>]

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

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.