在 2023/3/21 上午3:48, Michael S. Tsirkin 写道:
On Wed, Mar 15, 2023 at 08:55:45PM +0800, Heng Qi wrote:
We use the most basic GRE header fields (not NVGRE), not even optional
fields.
I'd say yes, the most convincing usecase is with legacy GRE.
Yes. But we still have a strong need for VXLAN and GENEVE to do
symmetric hashing. Please consider this.
Given that, do you need the rest of protocols there?
I would say that I checked the current tunneling protocols used for
overlay networks and their respective RFC versions compared to each other.
They are:
1. GRE_rfc2784 :This protocol is only specified for IPv4 and used as
either the payload or delivery protocol.
link : https://datatracker.ietf.org/doc/rfc2784/
2. GRE_rfc2890: This protocol describes extensions by which two fields,
Key and Sequence Number, can be optionally carried in the GRE Header.
link: https://www.rfc-editor.org/rfc/rfc2890
3. GRE_rfc7676: IPv6 Support for Generic Routing Encapsulation (GRE).
This protocol is specified for IPv6 and used as either the payload or
delivery protocol.
Note that this does not change the GRE header format or any
behaviors specified by RFC 2784 or RFC 2890.
link: https://datatracker.ietf.org/doc/rfc7676/
4. GRE-in-UDP: GRE-in-UDP Encapsulation. This specifies a method of
encapsulating network protocol packets within GRE and UDP headers.
This GRE-in-UDP encapsulation allows the UDP source port field to
be used as an entropy field. This protocol is specified for IPv4 and
IPv6, and used as either the payload or delivery protocol.
link: https://www.rfc-editor.org/rfc/rfc8086
5. VXLAN: Virtual eXtensible Local Area Network.
link: https://datatracker.ietf.org/doc/rfc7348/
6. VXLAN-GPE: Generic Protocol Extension for VXLAN. This protocol
describes extending Virtual eXtensible Local Area Network (VXLAN) via
changes to the VXLAN header.
link: https://www.ietf.org/archive/id/draft-ietf-nvo3-vxlan-gpe-12.txt
7. GENEVE: Generic Network Virtualization Encapsulation.
link: https://datatracker.ietf.org/doc/rfc8926/
8. IPIP: IP Encapsulation within IP.
link: https://www.rfc-editor.org/rfc/rfc2003
9. NVGRE: Network Virtualization Using Generic Routing Encapsulation
link: https://www.rfc-editor.org/rfc/rfc7637.html
10. STT: Stateless Transport Tunneling. STT is particularly useful when
some tunnel endpoints are in end-systems, as it utilizes the
capabilities of the network interface card to improve performance.
link: https://www.ietf.org/archive/id/draft-davie-stt-08.txt
Among them, GRE_rfc2784, VXLAN and GENEVE are our internal requirements
for inner header hashing.
GRE_rfc2784 requires RSS hashing to different queues.
For the monitoring scenario I mentioned, VXLAN or GRE_rfc2890 also needs
to use inner symmetric hashing.
I know you mean to want this feature to only support GRE_rfc2784, since
it's the most convincing for RSS.
But RSS hashes packets to different queues for different streams.
For the same flow, it needs to hash it to the same queue.
So this doesn't distort the role of RSS, and I believe that for modern
protocols like VXLAN and others, inner symmetric hashing is still a
common requirement for other vendors using virtio devices.
So, can we make this feature support all the protocols I have checked
above, so that vendors can choose to support the protocols they want.
And this can avoid the addition of new tunnel protocols
in the near future as much as possible.
Do you think it's ok?
Again: I'm so sorry I didn't realize I missed this until I checked my
emails. 🙁😮
We can start with just legacy GRE (think about including IPv6 or not).
Given how narrow this usecase is, I'd be fine with focusing
just on this, and addressing more protocols down the road
with something programmable like BPF. WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
