date:20220113

Re: [vpp-dev] VXLAN and RSS

2022-01-13 Thread Florin Coras

Yup, completely forgot about that. Ignore the first point … 

Cheers, 
Florin

> On Jan 13, 2022, at 3:37 PM, Ole Troan  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  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 
>>>  >> > 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  >> > On Behalf Of Pim van Pelt via lists.fd.io 
>>> 
>>> Sent: Thursday, January 13, 2022 5:37 PM
>>> To: vpp-dev 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 
>>> 
>>>  
>>> 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 mailto:p...@ipng.nl>> 
>>> PBVP1-RIPE - http://www.ipng.nl/ 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 


-=-=-=-=-=-=-=-=-=-=-=-
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VXLAN and RSS

2022-01-13 Thread Ole Troan

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  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 
>>  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  On Behalf Of Pim van Pelt 
>> via lists.fd.io
>> Sent: Thursday, January 13, 2022 5:37 PM
>> To: vpp-dev 
>> 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  
>> 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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VXLAN and RSS

2022-01-13 Thread Florin Coras

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 
>  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   > On Behalf Of Pim van Pelt via lists.fd.io 
> 
> Sent: Thursday, January 13, 2022 5:37 PM
> To: vpp-dev 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 
> 
>  
> 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 mailto:p...@ipng.nl>> 
> PBVP1-RIPE - http://www.ipng.nl/ 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20710): https://lists.fd.io/g/vpp-dev/message/20710
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VXLAN and RSS

2022-01-13 Thread Joel Halpern via lists.fd.io

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  On Behalf Of Pim van Pelt via 
lists.fd.io
Sent: Thursday, January 13, 2022 5:37 PM
To: vpp-dev 
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 mailto:p...@ipng.nl>>
PBVP1-RIPE - 
http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20709): https://lists.fd.io/g/vpp-dev/message/20709
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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VXLAN and RSS

2022-01-13 Thread Pim van Pelt

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 
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20708): https://lists.fd.io/g/vpp-dev/message/20708
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] [csit-dev] Thu 13-Jan FD.io CSIT talk at LFN Developer & Testing Forum

2022-01-13 Thread Maciek Konstantynowicz (mkonstan) via lists.fd.io

Zoom link to the session per teamup link below: 
https://zoom.us/j/96267999834?pwd=UnBNM2NveXgyT3BpdkNSenV2VjJjQT09

We will post the materials on the event wiki link listed below and in fd.io 
wiki, will send links.

> On 11 Jan 2022, at 15:58, Maciek Konstantynowicz (mkonstan) via lists.fd.io 
>  wrote:
> 
> Dear All,
> 
> Some of us from CSIT will be giving a talk at this week LFN Developer &
> Testing Forum (virtual event via Zoom, and it’s free to attend).
> 
> Title: FD.io CSIT Performance Benchmarking, Anomaly Detection, Results 
> Tracking.
> 
> Time: Thursday 13th January 2021 13:00-14:00 GMT (London)
> 
> Abstract: 
> 
> In this talk we introduce FD.io CSIT core sub-project and give an
> overview of the ways its Presentation-Analytics-Layer component
> presents test results. We will focus on performance results and anomaly
> detection, as a way to distinguish (probably) real performance changes
> from the noisy data. And provide a sneak peak into the way test results
> data is processed. Will use performance data from CI/CD automated tests
> executed on Intel Xeon(skx, clx, icx), Atom, Arm servers running in
> labs hosted by LFN FD.io. If you are interested in network performance
> testing in general, or FD.io project specifically, this talk is for
> you.
> 
> For FD.io CSIT session details see: 
> 
>https://wiki.lfnetworking.org/pages/viewpage.action?pageId=65538382
> 
> Event details and how to register: 
> 
>https://wiki.lfnetworking.org/pages/viewpage.action?pageId=53609047
> 
> Detailed schedule (make sure to select your timezone): 
> 
>https://teamup.com/ksgw6qzqcmg9zbzsfq?date=2022-01-10=md4
> 
> Cheers,
> Maciek
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20707): https://lists.fd.io/g/vpp-dev/message/20707
Mute This Topic: https://lists.fd.io/mt/88395628/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] L2/L3 cross-connect allows pinging an interface located in a deleted netns

2022-01-13 Thread Artem Glazychev

Hi Stanislav,

Perhaps you are right (but from my point of view it is strange).
And I can suggest the following configuration. We don't use vpp at all:

# ip netns add vpp1
# ip netns add vpp2

# ip link add veth1 type veth peer name veth2

# ip link set veth1 netns vpp1
# ip link set veth2 netns vpp2

# ip netns exec vpp1 ip link set veth1 up
# ip netns exec vpp1 ip addr add 10.10.1.1/24 dev veth1

# ip netns exec vpp2 ip link set veth2 up
# ip netns exec vpp2 ip addr add 10.10.1.2/24 dev veth2

# ip netns exec vpp1 ping 10.10.1.2

Ping works.

Delete vpp2 netns:

# ip netns delete vpp2

Ping stops.

I think this is correct behavior.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20706): https://lists.fd.io/g/vpp-dev/message/20706
Mute This Topic: https://lists.fd.io/mt/88392642/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] L2/L3 cross-connect allows pinging an interface located in a deleted netns

2022-01-13 Thread Stanislav Zaikin

Hi Artem,

As far as I know, netns in the host is just a binding (mounting point) to
the netns. If you delete the file (in /var/run/netns/ or something), you
just lose the way to connect to it. But the netns will be still in the
kernel until you delete all the interfaces from it (maybe except lo).

On Thu, 13 Jan 2022 at 08:35, Artem Glazychev 
wrote:

> Hello all,
>
> I ran into a problem when working with l2/l3 cross connect.
>
> For example, I create two *tap* interfaces in different network
> namespaces and L2 cross-connect inside a vpp instance. Set up addresses -
> ping works.
> But, if i delete the target namespace from the host - ping continues to
> work.
> I've tested it with *l2xc/l3xc + tap/tun* - the result is the same.
> Moreover, I see the same behavior with *l2xc + **af-packet* if I
> configure it via *vpp api*. But unfortunately I can't reproduce it using
> *vppctl*...
> Does anyone have any idea?
>
> I've created a JIRA issue with steps to reproduce -
> https://jira.fd.io/browse/VPP-2006
>
> Thanks
>
> 
>
>

-- 
Best regards
Stanislav Zaikin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20705): https://lists.fd.io/g/vpp-dev/message/20705
Mute This Topic: https://lists.fd.io/mt/88392642/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VXLAN and RSS

Re: [vpp-dev] VXLAN and RSS

Re: [vpp-dev] VXLAN and RSS

Re: [vpp-dev] VXLAN and RSS

[vpp-dev] VXLAN and RSS

Re: [vpp-dev] [csit-dev] Thu 13-Jan FD.io CSIT talk at LFN Developer & Testing Forum

Re: [vpp-dev] L2/L3 cross-connect allows pinging an interface located in a deleted netns

Re: [vpp-dev] L2/L3 cross-connect allows pinging an interface located in a deleted netns

8 matches

Site Navigation

Mail list logo

Footer information