[P4] Meres

Sandor Laki lakis at elte.hu
Mon Dec 14 15:29:45 CET 2015 

Mérd már ki a dpdk l2fwd esetén is performance-t.

Más: a p4 esetén még mindig broadcastol? Ha igen, akkor az is lassít...

Üdv.
Sanyi

2015.12.14. 15:11 keltezéssel, Péter Vörös írta:
> Most futtatom, az a 10Gb/s kartyat ami ebben a gepben van totalban kihasznalja.
>
> Sandor Laki <lakis at elte.hu> írta (2015. december 14. 15:02):
>> Hi,
>>
>> Nyomnál egy dpdk l2fwd-ot is? Csak, hogy lássuk azt is...
>>
>> Üdv.
>> Sanyi
>>
>>
>> 2015.12.14. 14:46 keltezéssel, Péter Vörös írta:
>>> A perf vizsgalat eredmenye:
>>>
>>>     33.39%  example_dpdk1  [.] crc32
>>>     28.76%  example_dpdk1  [.] packet_received
>>>      7.71%  example_dpdk1  [.] apply_table_smac
>>>      5.61%  example_dpdk1  [.] rx_recv_pkts
>>>
>>> Volt annak valami jelentossege, hogy a CRC szamolats sajat magunk
>>> implementaltuk?
>>> Lecsereltem a sajat implementacionkat a rte_hash_crc.h-ben
>>> implementaltra (rte_hash_crc), ezzel javult jelentosen a dolog
>>> 2.2Gb-nel jarunk.
>>>
>>> Peti
>>>
>>> Péter Vörös <vopraai at caesar.elte.hu> írta (2015. december 14. 14:34):
>>>> A calloc-ot kivezettem a while(1)-bol, ezzel ~1.5Gb/s re nott a
>>>> sebesseg, ennel meg mindig jobbnak kellene lennunk.
>>>>
>>>> Péter Vörös <vpetya at mensa.hu> írta (2015. december 14. 14:23):
>>>>> Sziasztok!
>>>>>
>>>>> Na sikerult beizzitani a merest, kiszedtem a printeket, O3mal
>>>>> forditok, meg egy kicsit buzeraltam a kodot ezzel feltornaztam a
>>>>> teljesitmenyunket 1.3Gb/s-re.
>>>>>
>>>>> Amugy bekapcsoltam az RSS-t, de egyelore nem vezet javulashoz, mert ez
>>>>> a hardware nem, illetve nem ugy tamogatja az RSS-t. Az Ericssonosokkal
>>>>> egyeztettem mar egy csomot, azt mondtak 1. korben nem is olyan rossz
>>>>> ez a szam, foleg ugy hogy meg calloc-olunk. De RSS nelkul el lehetne
>>>>> erni a 19Gb/s-t szoval ahogy mondtak: "van meg rejtett eroforras amit
>>>>> ki kellene hasznalni".
>>>>> Szoval azt mondtak, hogy RSS nelkul probaljuk novelni ezt a szamot.
>>>>>
>>>>> Jelenleg epp azt nezem hogy miert nem tobbet, a hibe valszeg, hogy meg
>>>>> mindig van calloc fast path-on:
>>>>> init_metadata(packet_descriptor_t* packet_desc, uint32_t inport)
>>>>> {
>>>>>       packet_desc->headers[header_instance_standard_metadata] =
>>>>>         (header_descriptor_t) {
>>>>>           .type = header_instance_standard_metadata,
>>>>>           .length =
>>>>> header_instance_byte_width[header_instance_standard_metadata],
>>>>> ****
>>>>> ****   .pointer =
>>>>> calloc(header_instance_byte_width[header_instance_standard_metadata],
>>>>> sizeof(uint8_t)) ****
>>>>> ****
>>>>>         };
>>>>>       modify_field_to_const(packet_desc,
>>>>> field_desc(field_instance_standard_metadata_ingress_port),
>>>>> (uint8_t*)&inport, 2);
>>>>> }
>>>>>
>>>>> Ezt minden csomagnal megcsinaljuk es valszeg nem tul egeszseges a
>>>>> teljesitmeny szempontjabol.
>>>>>
>>>>> Peti
>>>>>
>>>>> Tejfel Máté <matej at caesar.elte.hu> írta (2015. december 14. 9:54):
>>>>>> Sziasztok!
>>>>>>
>>>>>>     Most látom (most a logot is meg tudtam nézni :) ), hogy teljesen
>>>>>> félreértettem Sanyi első levelét. Azt hittem már a controllertől se jön
>>>>>> meg
>>>>>> a válasz, ezért broadcastol. Viszont ezek szerint funkcionálisan
>>>>>> igazából
>>>>>> jól működik. Így akkor tényleg nincs sok jelentősége a
>>>>>> generate_digest-nek...
>>>>>>
>>>>>>          M.
>>>>>>
>>>>>>
>>>>>> 2015-12-13 22:05 keltezéssel, Sandor Laki írta:
>>>>>>> Várhatóan a generate_digest nem jelent sokat, mivel az csak az első
>>>>>>> csomagnál hívódik meg.
>>>>>>>
>>>>>>> Üdv.
>>>>>>> Sanyi
>>>>>>>
>>>>>>> 2015.12.13. 14:42 keltezéssel, Tejfel Máté írta:
>>>>>>>> Sziasztok!
>>>>>>>>
>>>>>>>>     Peti, amit még esetleg kipróbálhatnál, hogy a pénteki konfignál,
>>>>>>>> ha már
>>>>>>>> úgyis mindig broadcast-ol,
>>>>>>>>      a) mi van, ha az actions.c-ben, az action_code_mac_learn végén
>>>>>>>> nem
>>>>>>>> csak a sleep(1)-et kommentezed ki, hanem a generate_digest-et is,
>>>>>>>> illetve
>>>>>>>>      b) mi van, ha a teljes action_code_mac_learn-t kikommentezed
>>>>>>>>      (persze mindkettőnél az összes print eltüntetése mellett)
>>>>>>>>      Ez is tanulságos eredményt adhat...
>>>>>>>>
>>>>>>>>    PS: a gcc-t ugye -O3 flag-el futtatod, had optimalizáljon, amit
>>>>>>>> tud?
>>>>>>>>
>>>>>>>>                     M.
>>>>>>>>
>>>>>>>> 2015-12-12 23:16 keltezéssel, Péter Vörös írta:
>>>>>>>>> Igen köszi a tippet, erre már gondoltam én is, de a broadcastolás
>>>>>>>>> miatt egyáltalán nem lehetett mérni a teljesítményt szóval először
>>>>>>>>> azt
>>>>>>>>> akartam áthidalni.
>>>>>>>>> Ha már megérkeznek jól a csomagok, akkor kikommentezem a printeket a
>>>>>>>>> további mérésekhez.
>>>>>>>>>
>>>>>>>>> Peti
>>>>>>>>>
>>>>>>>>> Sandor Laki <lakis at elte.hu> írta (2015. december 12. 23:11):
>>>>>>>>>> Ami még megfoghatja, a logolás, azaz a sok println...
>>>>>>>>>>
>>>>>>>>>> Üdv.
>>>>>>>>>> Sanyi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2015.12.12. 22:14 keltezéssel, Péter Vörös írta:
>>>>>>>>>>> Szia,
>>>>>>>>>>>
>>>>>>>>>>> Oké, hétfőn kipróbálom.
>>>>>>>>>>> A l2fwd-t nem néztem meg mert a srácok azt mondták, hogy
>>>>>>>>>>> felesleges,
>>>>>>>>>>> látták már ezerszer, az tud 25Gb/s-t. De csak hogy a configról
>>>>>>>>>>> megbizonyosodjak azt is lefuttatom majd.
>>>>>>>>>>>
>>>>>>>>>>> Peti
>>>>>>>>>>>
>>>>>>>>>>> Sandor Laki <lakis at elte.hu> írta (2015. december 12. 21:46):
>>>>>>>>>>>> Szia,
>>>>>>>>>>>>
>>>>>>>>>>>> A backward maclearning miatt, mivel nem jön válasz az áttolt
>>>>>>>>>>>> csomagokra,
>>>>>>>>>>>> így
>>>>>>>>>>>> broadcastolni fog végig, ami elég műveletigényes, és ehhez lehet,
>>>>>>>>>>>> hogy
>>>>>>>>>>>> mempool is kicsi, ami most be van állítva. Persze mivel 2 portunk
>>>>>>>>>>>> van,
>>>>>>>>>>>> elvben a broadcastot is lehetne ügyesebben csinálni. Amit ki
>>>>>>>>>>>> tudsz
>>>>>>>>>>>> próbálni:
>>>>>>>>>>>> 1. az elején a port1-en is beküldesz egy csomagot a célállomás
>>>>>>>>>>>> mac
>>>>>>>>>>>> címével,
>>>>>>>>>>>> azaz a src mac ez legyen: 00:25:90:91:1B:2B. Eztán pedig
>>>>>>>>>>>> indíthatod a
>>>>>>>>>>>> korábbi kísérletet.
>>>>>>>>>>>> 2. a dpdk l2fwd példája mit tud? Azt kellene baseline-nak
>>>>>>>>>>>> tekinteni.
>>>>>>>>>>>> Ha
>>>>>>>>>>>> az
>>>>>>>>>>>> is lassú, akkor még van konfigurációs probléma is...
>>>>>>>>>>>>
>>>>>>>>>>>> Üdv.
>>>>>>>>>>>> Sanyi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2015.12.11. 16:09 keltezéssel, Péter Vörös írta:
>>>>>>>>>>>>
>>>>>>>>>>>> Sziasztok!
>>>>>>>>>>>>
>>>>>>>>>>>> Mar par oraja jatszok a teszt beinditasaval, valami tortenik.
>>>>>>>>>>>> Latszik
>>>>>>>>>>>> hogy kapunk egy rakalp csomagot, az viszont nekem nem tiszta,
>>>>>>>>>>>> hogy mi
>>>>>>>>>>>> az a pont ahol meghal.
>>>>>>>>>>>>
>>>>>>>>>>>> A baj az, hogy a leglassabb rate beallitasra is mar ez tortenik.
>>>>>>>>>>>> (ami
>>>>>>>>>>>> kb 100Mb/s)
>>>>>>>>>>>>
>>>>>>>>>>>> Megtudtam kozben a titkos szamot is kb 25Gb/s-t kellene tudnunk.
>>>>>>>>>>>>
>>>>>>>>>>>> Lehet, hogy valami nincs meg tokeletesen konfigolva, mert nem
>>>>>>>>>>>> ertem
>>>>>>>>>>>> miert akar mindig broadcastolni. Hetfon folytatom.
>>>>>>>>>>>>
>>>>>>>>>>>> Peti
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> P4 mailing list
>>>>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sándor Laki, PhD
>>>>>>>>>>>> Assistant professor
>>>>>>>>>>>> Department of Information Systems
>>>>>>>>>>>> Eötvös Loránd University
>>>>>>>>>>>> Pázmány Péter stny. 1/C
>>>>>>>>>>>> H-1117, Budapest, Hungary
>>>>>>>>>>>> Room 2.506
>>>>>>>>>>>> Web: http://lakis.web.elte.hu
>>>>>>>>>>>> Phone: +36 1 372 2869 / 8477
>>>>>>>>>>>> Cell: +36 70 374 2646
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> P4 mailing list
>>>>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> P4 mailing list
>>>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sándor Laki, PhD
>>>>>>>>>> Assistant professor
>>>>>>>>>> Department of Information Systems
>>>>>>>>>> Eötvös Loránd University
>>>>>>>>>> Pázmány Péter stny. 1/C
>>>>>>>>>> H-1117, Budapest, Hungary
>>>>>>>>>> Room 2.506
>>>>>>>>>> Web: http://lakis.web.elte.hu
>>>>>>>>>> Phone: +36 1 372 2869 / 8477
>>>>>>>>>> Cell: +36 70 374 2646
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> P4 mailing list
>>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>> _______________________________________________
>>>>>>>>> P4 mailing list
>>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> P4 mailing list
>>>>>>>> P4 at plc.inf.elte.hu
>>>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> P4 mailing list
>>>>>> P4 at plc.inf.elte.hu
>>>>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>> _______________________________________________
>>> P4 mailing list
>>> P4 at plc.inf.elte.hu
>>> https://plc.inf.elte.hu/mailman/listinfo/p4
>>
>>
>> --
>> Sándor Laki, PhD
>> Assistant professor
>> Department of Information Systems
>> Eötvös Loránd University
>> Pázmány Péter stny. 1/C
>> H-1117, Budapest, Hungary
>> Room 2.506
>> Web: http://lakis.web.elte.hu
>> Phone: +36 1 372 2869 / 8477
>> Cell: +36 70 374 2646
>>
>> _______________________________________________
>> P4 mailing list
>> P4 at plc.inf.elte.hu
>> https://plc.inf.elte.hu/mailman/listinfo/p4
> _______________________________________________
> P4 mailing list
> P4 at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/p4


-- 
Sándor Laki, PhD
Assistant professor
Department of Information Systems
Eötvös Loránd University
Pázmány Péter stny. 1/C
H-1117, Budapest, Hungary
Room 2.506
Web: http://lakis.web.elte.hu
Phone: +36 1 372 2869 / 8477
Cell: +36 70 374 2646

More information about the P4 mailing list