OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




å 2023/4/26 äå10:48, Michael S. Tsirkin åé:
On Wed, Apr 26, 2023 at 10:14:30PM +0800, Heng Qi wrote:
This does not mean that every device needs to implement and support all of
these, they can choose to support some protocols they want.

I add these because we have scale application scenarios for modern protocols
VXLAN-GPE/GENEVE:

+\item In scenarios where the same flow passing through different tunnels is expected to be received in the same queue,
+      warm caches, lessing locking, etc. are optimized to obtain receiving performance.


Maybe the legacy GRE, VXLAN-GPE and GENEVE? But it has a little crossover.

Thanks.
But VXLAN-GPE/GENEVE can use source port for entropy.

	It is recommended that the UDP source port number
	 be calculated using a hash of fields from the inner packet

That is best because
it allows end to end control and is protocol agnostic.

Yes. I agree with this, I don't think we have an argument on this point right now.:)

For VXLAN-GPE/GENEVE or other modern tunneling protocols, we have to deal with
scenarios where the same flow passes through different tunnels.

Having them hashed to the same rx queue, is hard to do via outer headers.

All that is missing is symmetric Toepliz and all is well?

The scenarios above or in the commit log also require inner headers.


Thanks.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]