[P4] Meres
Péter Vörös
vpetya at mensa.hu
Mon Dec 14 15:11:35 CET 2015
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
More information about the P4
mailing list