> From: Heng Qi <[email protected]> > Sent: Thursday, February 16, 2023 9:19 AM > >> I'm really okay with this, the tunnel type seems to help the software > >> driver do more things in the future, for example, the driver may not > >> want to use the outer hash value when forwarding packets. But if > >> there is really no practical scenario for the driver at present, then > >> let us hide the tunnel types in the \field{hash_report}? > >> > > Right. Lets omit hash_report in virtio_net_hdr. > > Ok. Will do. Ok. thanks.
> > > > >>> What is valuable is to have a VNI already identified and coming to > >>> the driver, > >> like a hash value. > >> > >> This is too specific to a certain tunnel protocol, not every protocol > >> has corresponding VNI information. > >> > > True. I was considering a hash of the generic outer header through which it > can reach to generic tunnel. > > But it is a very different feature of its own, so yes, better to split and > > proceed > with this to improve inner hash. > > It's a good idea, but I think the current work needs to focus on the inner > header > hash, and the more general features we can continue in other work. > Right. May be my previous comment didn’t clarify that enough. We both are saying same point to not focus on outer header optimization in these series. :)
