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

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

å 2023/3/16 äå7:24, Parav Pandit åé:
> On 3/15/2023 8:10 AM, Michael S. Tsirkin wrote:
> > On Tue, Mar 14, 2023 at 11:23:55PM -0400, Parav Pandit wrote:
> > > If not, for now it may be better to skip vxlan and nvegre as they 
> > > inherently
> > > have unique outer header UDP src port based on the inner header.
> >
> > So what's left, GRE? GRE is actually different, in that it's not IP at
> > all.
> Sorry, I wrongly wrote nvegre above.
>
> IPoIP, GRE and NVGRE are left.
>
> vxlan and geneve has the udp src entropy.
>
> >
> Not sure I understand "its not IP at all".
>
> GRE has outer IP header + GRE header with the key to identify the flow.
> The key is effectively the hash for the flow.
>
> > So if we are talking about GRE, hash is indeed not calculated at all at
> > the moment, right? 
> Hash of the outer IP header of the src and dst IP can be still 
> calculated currently for GRE when the optional key is not present.
>
> > And I would say a natural first step for GRE is
> > actually adding a hash type that will support this protocol.
> For GRE and NVGRE GRE_header.key as the flow/hash identifier should 
> work without inner header hash.
> Older version of the GRE doesn't have key, so inner header hash is 
> useful.

Yes, indeed.
The old GRE does not have keys such as flow id. Even with the new GRE, 
we have no chance to use optional fields,
because we have connected with various operators, and the most basic 
fields can get the best compatibility.

Thanks.

> > How about doing that? It seems like this should be a small step
> > and completely uncontroversial.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org