Florin, Actually no. Geneve isn’t like a typical UDP application where receiver reverses the ports. The IANA allocated port is used as the destination port in both directions. Making the source port purely used for entropy.
Of course for v6 the whole UDP header would largely be superfluous. Cheers Ole > On 14 Jan 2022, at 00:26, Florin Coras <fcoras.li...@gmail.com> wrote: > > Hi Pim, > > If multiple source ports are to be used, probably those should be consumed > through transport_alloc_local_endpoint (see for instance udp_open_connection) > to play nicely with the rest of the host stack. > > Alternatively, although I never tried it, try something like "set > flow-offload vxlan ..” if you’re using dpdk. > > Regards, > Florin > >> On Jan 13, 2022, at 3:15 PM, Joel Halpern via lists.fd.io >> <joel.halpern=ericsson....@lists.fd.io> wrote: >> >> I can’t tell you what it would take to modify the code. >> >> I can observe that RFC 8926 section 3.3 explicitly states that the source >> port should be stable for a given flow, and should be varied across flows. >> It specifically suggests that “the source port SHOULD be calculated using a >> hash of the encapsulated packet headers using, for example, a traditional >> 5-tuple.” >> >> Yours, >> Joel >> >> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Pim van Pelt >> via lists.fd.io >> Sent: Thursday, January 13, 2022 5:37 PM >> To: vpp-dev <vpp-dev@lists.fd.io> >> Subject: [vpp-dev] VXLAN and RSS >> >> Hoi folks, >> >> I did a deep dive today on VXLAN, GENEVE and compared it to GRE and L2XC - >> the full read is here: >> https://ipng.ch/s/articles/2022/01/13/vpp-l2.html >> >> One thing that I observed is that both VXLAN and GENEVE use static source >> ports. In the case of VLLs, (an l2 xconnect from a customer ethernet >> interface into a tunnel), the customer port will be receiving IPv4 or IPv6 >> traffic (either tagged or untagged) and this allows the NIC to use RSS to >> assign this inbound traffic to multiple queues, and thus multiple CPU >> threads. That’s great, it means linear encapsulation performance. >> However,, once the traffic is encapsulated, it’ll become single flow with >> respect to the remote host, ie we're sending from 10.0.0.0:4789 to the >> remote 10.0.0.1:4789 and it is for this reason, that all decapsulation is >> single threaded. >> One common approach is to use an ingress hash algorithm to choose from a >> pool of source ports, or possibly a simpler round-robin over a pool of ports >> 4000-5000, say, based on the inner payload. That way, the remote would be >> able to use multiple RSS queues. However, VPP currently does not implement >> that. >> >> I think the original author has this in mind as a future improvement based >> on the comment on L295 in vxlan.c >> /* UDP header, randomize src port on something, maybe? */ >> udp->src_port = clib_host_to_net_u16 (t->src_port); >> udp->dst_port = clib_host_to_net_u16 (t->dst_port); >> >> What would it take for src_port to not be static? It would greatly improve >> VXLAN (and similarly, GENEVE) throughput on ingress. >> >> groet, >> Pim >> -- >> Pim van Pelt <p...@ipng.nl> >> PBVP1-RIPE - http://www.ipng.nl/ >> >> >> > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20711): https://lists.fd.io/g/vpp-dev/message/20711 Mute This Topic: https://lists.fd.io/mt/88408739/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
