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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Mar 21, 2023 at 07:46:14PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, March 21, 2023 3:37 AM
> > 
> > On Tue, Mar 21, 2023 at 04:19:17AM +0000, Parav Pandit wrote:
> > > One (this proposal) is solving spread to different RSS queues.
> > 
> > Spread is mostly ok with modern protocols though. 
> Yes. 
> > It seems to optimize for a specific monitoring solution.
> > 
> Monitoring is a critical part of the infrastructure.
> So, if a point solution is useful, at least I don't see a negative of it especially when there is a user of it.


Yes. I'd like to include just the protocols that genuinely benefit
though, so we can avoid the churn of adding more and more tunneling
protocols as they appear.

That's why I am trying to find out whether limiting this to
just classic GRE is ok (and maybe GRE IPv6).

I also feel if symmetry is needed we need support for xor based thing
with a mask, playing with toeplitz is fragile due to e.g. IPv4/IPv6
headers being different length.

> > > Another one is finding out which exact packet to drop/pass when queue usage
> > is high. (ebpf/tc other ways to solve it).
> > >
> > > Ebpf sounds cooler than the real offload implementation in the hw device at
> > the current level.
> > > I remember Jason's good talk on the ebpf a few years back, which is possible
> > when done in sw on the hypervisor.
> > 
> > I was talking about classic bpf though. no state.
> > 
> Packet processing logic requires to keep track of past tunnel data and counters across many queues for fairness.
> This involves stateful ness of past/current data.
> 
> Even with outer header entropy, multiple tunnels can steer to a small set of queues, because num_tunnel >= num_queues.
> Hence, fairness is orthogonal.

Yes I was not talking about fairness. that was addressed adequately with
a security note I feel.

-- 
MST