Re: [opnfv-tech-discuss] [opnfv-tsc] Now Open: LFN Unconference Track at ONS Europe

[Trevor Cooper]

I have added a topic specifically on “Test frameworks and tools for CNTT” to 
follow up the discussion started in Paris on OPNFV test framework strategy for 
CNTT reference implementations and compliance program.

/Trevor

From: opnfv-...@lists.opnfv.org  On Behalf Of 
Brandon Wick
Sent: Wednesday, July 31, 2019 9:31 AM
Subject: [opnfv-tsc] Now Open: LFN Unconference Track at ONS Europe

LFN Technical Communities,

For those planning to attend ONS 
Europe,
 we wanted to let you you that once again LF Networking will be hosting an LFN 
Unconference Track throughout the event. This is a meeting space for projects 
in the LF Networking initiative for project work, topic discussions, and 
small-team breakouts.

We call this an “unconference” because it’s less about pre-arranged formal 
presentations, and instead allows for discussions to “spring up” before the 
event or at the event itself. Unconference sessions should be focused on 
interaction and collaboration between attendees.

If you work in any of the LF Networking project communities, we welcome you to 
add your topics/ideas to the unconference wiki and use this meeting space for 
teamwork throughout the event.

Please add your initial unconference meeting ideas by Friday. August 16th. A 
schedule will be published the following week with some slots held for on-site 
programming. Learn more on the ONS website 
here
 and add your topics to the LFN Unconference wiki page 
here.

Please let us know if you have any questions.

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
bw...@linuxfoundation.org
+1.917.282.0960

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23409): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23409
Mute This Topic: https://lists.opnfv.org/mt/32673833/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] Weekly Technical Discussion #147

[HU, BIN]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="HU, BIN":MAILTO:bh5...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tech
 -disc...@lists.opnfv.org:MAILTO:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=opnfv-tsc@
 lists.opnfv.org:MAILTO:opnfv-...@lists.opnfv.org
DESCRIPTION;LANGUAGE=en-US:https://zoom.us/j/2362828999\n+1-877-369-0926 or
  +1-855-880-1246 / Meeting ID: 236 282 8999\n\nHello community:\n\nThis is
  our 147th weekly technical discussion at 6am PDT / 9am EDT Monday August 
 5th\, 2019\, which is 13:00 UTC.\n\nTrevor Cooper will continue to lead the discussion of LFN SPC’s Question
 naire.\n\nYou can find y
 our local time here http://www.timeanddate.com/worldclock/fixedtime.html?m
 sg=OPNFV-Technical-Discussion=20190805T13=1.\n\nPlease refer to htt
 ps://wiki.opnfv.org/display/PROJ/Weekly+Technical+Discussion for details o
 f dialing logistics and tentative agenda.\n\nPlease let me know if you wan
 t to add anything to agenda for discussion in the community.\n\nFor your c
 onvenience:\n\n  *   Zoom Meeting: https://zoom.us/j/2362828999\n  *   You
  can also dial in using your phone:\n *   United States (Long distance
 ): +1-669-900-6833 or +1 646 558 8656\n *   United States (Toll Free):
  +1-877-369-0926 or +1-855-880-1246\n *   Meeting ID: 236 282 8999\n  
*   International numbers available: https://zoom.us/zoomconference?m=X
 n-Kas4jq2GuyfbCCKYpwvi6FpHEYX8n\n  *   More information about OPNFV Confer
 encing Bridge:\
 n\nThanks\nBin\n
SUMMARY;LANGUAGE=en-US:Weekly Technical Discussion #147
DTSTART;TZID=Pacific Standard Time:20190805T06
DTEND;TZID=Pacific Standard Time:20190805T07
UID:04008200E00074C5B7101A82E008107996C2BD47D501000
 0100027C47078EB532F4EB7D816D9D183AC4C
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20190731T233556Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:https://zoom.us/j/2362828999
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-1535150109
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23408): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23408
Mute This Topic: https://lists.opnfv.org/mt/32673459/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] #nfvbench - Looking for line rate performances using NFVbench - UPDATED

[via Lists.Opnfv.Org]

Hi Alec,

I'm Pierrick Louin working in the team of François-Régis Menguy @orange-Labs.

In our last experiments, using the NFVbench application, we came across some 
issues and a workaround in trying to reach high performances from the bench at 
a high line rate.
Maybe you can help us understanding what happens in the following observations.

The raw traces are joined as text files.



CONFIGURATION & SOFTWARE


Those reference tests are performed over a simple loopback link between the 2 
ports of a NIC (either wired or through a hardware switch).
We studied the two following cases:

NIC Intel X520 (10 Gbits/s)
NIC Mellanox ConnectX-5 (25 Gbits/s)

Note that the list of the cpu threads reserved to the generator is not 
optimized. There is room for tuning...
However this was not the point in these tests since, as we will see, the 
performance issue appears related to the RX process.

The T-Rex generator will run with the same settings whether it is used 
standalone or wrapped in the NFVbench.

TRex version: v2.59
NFVbench version: 3.5.0 (3.5.1.dev1)

Warning: I found that the NFVbench performance are improved - in mellanox tests 
- provided that a T-Rex server has been launched/stopped once before and since 
the last reboot.

Otherwise no way to obtain a 2 x 25 Gbits/s TX throughput but only ~ 2 x 5.2 
Gbits/s with Mellanox.
We have to investigate  this T-Rex issue which is not addressed thereafter 
(some different initial module loading ?).

We have slightly patched the NFVbench code in order to make some processing now 
optional and/or configurable from the command line (some for debugging purpose).

--cores CMD_CORES   Override the T-Rex 'cores' parameter
--cache-size CACHE_SIZE Specify the FE cache size (default: 0, flow-count if < 
0)
--service-mode  Enable T-Rex service mode
--extra-stats   Enable extra flow stats (on high load traffic)
--no-latency-stats  Disable flow stats for latency traffic
--no-latency-streamsDisable latency measurements (no streams)
--ipdb-mask IPDB_MASK   Allow specific breakpoints for the ipdb debugger)

TESTS
*

We consider the smallest packet size (64 bytes L2) in order to assess the 
maximum throughput achievable.

Four tests are performed for each of the NICs tested - with a 100% and NDR rate.

1) Preliminary tests, performed with a basic scenario: 'pik.py' launched from a 
T-Rex console (derived from the script 'bench.py' coming with the T-Rex appli).

2) Tests performed using NFVbench (v3.5.0) in its native coding:
 High-rate generic streams (for BW measurement) and Low-rate streams (for 
Latency assessment) are configured into the T-Rex generator in order to allow 
stats computing on transmitted/received streams.

Actually we had however left a 1 hard coded cache_size specification when 
calling STLScVmRaw() in 'trex_gen.py' in all the cases even this one.



ð  This caching mode allows far better performances.

(In our code release, we now control this parameter from a command line 
parameter)

3) Tests performed using NFVbench where we have disabled into the 'trex_gen.py' 
script the instructions to tag the traffic generated for the purpose of further 
statistics (as far as we understand it) - this change is made in calls to 
STLStream().

4) Tests performed using NFVbench where we keep the flow stats property for the 
latency streams only.

FIRST ANALYSIS


The T-Rex test allows us to check that we have no bottleneck on the 
generator/analyzer + SUT side.

The NFVbench results show acceptable performances only when dealing with the 10 
Gbits/sec line.

Using the NFVbench with its unmodified behaviour (case 2) the line rate is far 
from being reached with a 50 Gpbs line:


ð  8.56 Gbits/s instead of 50 Gbits/s (L1)

Unless there are some special reasons for activating a heavy flow stats RX 
processing, we suggest working in the case (4).

We keep the latency assessment while the traffic counters seem to suffice at 
measuring the BW performances.

Of course it may depend on the NIC capabilities for offloading traffic 
measurements.
This is why we also make the flow stat activation optional.

FURTHER ANALYSIS
***

However, looking closer to the performances obtained in the case (3),
we can see a significantly reduced rate at the TX (and therefore RX) side:

19.09 Gbits/s instead of 20 Gbtts/s (L1) - value is stable between launches
48.42 Gbits/s instead of 50 Gbits/s (L1) - actually variable between launches

Note that the NDR measurement does not show any warning then.

This is not our target case but it made me thinking...

Thus, I tried a (5) case where we keep the flow stats for BW streams only.

  - the TX packet rate is reduced as in the case (3) for the Intel x520
  - the throughput is limited by the line rate for the Mellanox ConnectX-5

<=> this is unexpected regarding to our 

[opnfv-tech-discuss] Now Open: LFN Unconference Track at ONS Europe

[Brandon Wick]

LFN Technical Communities,

For those planning to attend ONS Europe
,
we wanted to let you you that once again LF Networking will be hosting
an LFN Unconference Track throughout the event. This is a meeting space for
projects in the LF Networking initiative for project work, topic
discussions, and small-team breakouts.

We call this an “unconference” because it’s less about pre-arranged formal
presentations, and instead allows for discussions to “spring up” before the
event or at the event itself. Unconference sessions should be focused on
interaction and collaboration between attendees.

If you work in any of the LF Networking project communities, we welcome you
to add your topics/ideas to the unconference wiki and use this meeting
space for teamwork throughout the event.

*Please add your initial unconference meeting ideas by Friday. August 16th*.
A schedule will be published the following week with some slots held for
on-site programming. Learn more on the ONS website here

and add your topics to the LFN Unconference wiki page here

.

Please let us know if you have any questions.

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
bw...@linuxfoundation.org
+1.917.282.0960
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23406): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23406
Mute This Topic: https://lists.opnfv.org/mt/32668761/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] #nfvbench - Looking for line rate performances using NFVbench - UPDATED

[Pierrick Louin via Lists.Opnfv.Org]

Hi Alec,

I'm Pierrick Louin working in the team of François-Régis Menguy @orange-Labs.

In our last experiments, using the NFVbench application, we came across some 
issues and a workaround in trying to reach high performances from the bench at 
a high line rate.
Maybe you can help us understanding what happens in the following observations.

The raw traces are joined as text files.

(sorry for resending, I hope my subscription works at last)



CONFIGURATION & SOFTWARE


Those reference tests are performed over a simple loopback link between the 2 
ports of a NIC (either wired or through a hardware switch).
We studied the two following cases:

NIC Intel X520 (10 Gbits/s)
NIC Mellanox ConnectX-5 (25 Gbits/s)

Note that the list of the cpu threads reserved to the generator is not 
optimized. There is room for tuning...
However this was not the point in these tests since, as we will see, the 
performance issue appears related to the RX process.

The T-Rex generator will run with the same settings whether it is used 
standalone or wrapped in the NFVbench.

TRex version: v2.59
NFVbench version: 3.5.0 (3.5.1.dev1)

Warning: I found that the NFVbench performance are improved - in mellanox tests 
- provided that a T-Rex server has been launched/stopped once before and since 
the last reboot.

Otherwise no way to obtain a 2 x 25 Gbits/s TX throughput but only ~ 2 x 5.2 
Gbits/s with Mellanox.
We have to investigate  this T-Rex issue which is not addressed thereafter 
(some different initial module loading ?).

We have slightly patched the NFVbench code in order to make some processing now 
optional and/or configurable from the command line (some for debugging purpose).

--cores CMD_CORES   Override the T-Rex 'cores' parameter
--cache-size CACHE_SIZE Specify the FE cache size (default: 0, flow-count if < 
0)
--service-mode  Enable T-Rex service mode
--extra-stats   Enable extra flow stats (on high load traffic)
--no-latency-stats  Disable flow stats for latency traffic
--no-latency-streamsDisable latency measurements (no streams)
--ipdb-mask IPDB_MASK   Allow specific breakpoints for the ipdb debugger)

TESTS
*

We consider the smallest packet size (64 bytes L2) in order to assess the 
maximum throughput achievable.

Four tests are performed for each of the NICs tested - with a 100% and NDR rate.

1) Preliminary tests, performed with a basic scenario: 'pik.py' launched from a 
T-Rex console (derived from the script 'bench.py' coming with the T-Rex appli).

2) Tests performed using NFVbench (v3.5.0) in its native coding:
 High-rate generic streams (for BW measurement) and Low-rate streams (for 
Latency assessment) are configured into the T-Rex generator in order to allow 
stats computing on transmitted/received streams.

Actually we had however left a 1 hard coded cache_size specification when 
calling STLScVmRaw() in 'trex_gen.py' in all the cases even this one.



ð  This caching mode allows far better performances.

(In our code release, we now control this parameter from a command line 
parameter)

3) Tests performed using NFVbench where we have disabled into the 'trex_gen.py' 
script the instructions to tag the traffic generated for the purpose of further 
statistics (as far as we understand it) - this change is made in calls to 
STLStream().

4) Tests performed using NFVbench where we keep the flow stats property for the 
latency streams only.

FIRST ANALYSIS


The T-Rex test allows us to check that we have no bottleneck on the 
generator/analyzer + SUT side.

The NFVbench results show acceptable performances only when dealing with the 10 
Gbits/sec line.

Using the NFVbench with its unmodified behaviour (case 2) the line rate is far 
from being reached with a 50 Gpbs line:


ð  8.56 Gbits/s instead of 50 Gbits/s (L1)

Unless there are some special reasons for activating a heavy flow stats RX 
processing, we suggest working in the case (4).

We keep the latency assessment while the traffic counters seem to suffice at 
measuring the BW performances.

Of course it may depend on the NIC capabilities for offloading traffic 
measurements.
This is why we also make the flow stat activation optional.

FURTHER ANALYSIS
***

However, looking closer to the performances obtained in the case (3),
we can see a significantly reduced rate at the TX (and therefore RX) side:

19.09 Gbits/s instead of 20 Gbtts/s (L1) - value is stable between launches
48.42 Gbits/s instead of 50 Gbits/s (L1) - actually variable between launches

Note that the NDR measurement does not show any warning then.

This is not our target case but it made me thinking...

Thus, I tried a (5) case where we keep the flow stats for BW streams only.

  - the TX packet rate is reduced as in the case (3) for the Intel x520
  - the throughput is limited by the line rate for the 

[opnfv-tech-discuss] OPNFV & CNTT discussion during ONS LFN unconference sessions

[fuqiao]

Hi, all. I have proposed an unconference session during the Atwerp ONS to drive 
the discussion for OPNFV related planning for CNTT activities. Based on the 
discussion yesterday, I think the community would be interested in learn more 
about the CNTT progress, and also have a place where we OPNFVers could spend 
some time talking about our stretagy and plannings. I think this will be a good 
opportunity.

https://wiki.lfnetworking.org/display/LN/2019+ONS+EU+September+Unconference+Topic+Proposals

See if you are interested in the session and have any suggestions?




中国移动研究院
网络与IT技术研究所
付乔 15901025951
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23404): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23404
Mute This Topic: https://lists.opnfv.org/mt/32665293/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[opnfv-tech-discuss] [dovetail] Cancelled Dovetail weekly meeting

[xudan]

Hi all,

I'd like to cancel today's Dovetail meeting because I will on a business trip 
and some major members are still on vacation. See you next week.

Thanks,
Dan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#23403): 
https://lists.opnfv.org/g/opnfv-tech-discuss/message/23403
Mute This Topic: https://lists.opnfv.org/mt/32665041/21656
Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org
Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-