Yup, completely forgot about that. Ignore the first point … Cheers, Florin
> On Jan 13, 2022, at 3:37 PM, Ole Troan <otr...@employees.org> wrote: > > 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 >>> <http://lists.fd.io/> <joel.halpern=ericsson....@lists.fd.io >>> <mailto: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 <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io >>> <mailto:vpp-dev@lists.fd.io>> On Behalf Of Pim van Pelt via lists.fd.io >>> <http://lists.fd.io/> >>> Sent: Thursday, January 13, 2022 5:37 PM >>> To: vpp-dev <vpp-dev@lists.fd.io <mailto: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 >>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-eb58b434aa85fefe&q=1&e=da8dd7f1-6228-4705-822d-acdf096c6cbb&u=https%3A%2F%2Fipng.ch%2Fs%2Farticles%2F2022%2F01%2F13%2Fvpp-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 >>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b084ba08ac5cdbf&q=1&e=da8dd7f1-6228-4705-822d-acdf096c6cbb&u=http%3A%2F%2F10.0.0.0%3A4789%2F> >>> to the remote 10.0.0.1:4789 >>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-92908955b444a8b7&q=1&e=da8dd7f1-6228-4705-822d-acdf096c6cbb&u=http%3A%2F%2F10.0.0.1%3A4789%2F> >>> 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 <mailto:p...@ipng.nl>> >>> PBVP1-RIPE - http://www.ipng.nl/ >>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-370b7382a99e002e&q=1&e=da8dd7f1-6228-4705-822d-acdf096c6cbb&u=http%3A%2F%2Fwww.ipng.nl%2F> >>> >>> >> >> >> >>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20712): https://lists.fd.io/g/vpp-dev/message/20712 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] -=-=-=-=-=-=-=-=-=-=-=-
