[P4] Meres

Sandor Laki lakis at elte.hu
Mon Dec 14 15:02:55 CET 2015 

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

More information about the P4 mailing list