[P4] Meres

Péter Vörös vopraai at caesar.elte.hu
Mon Dec 14 14:46:44 CET 2015 

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

More information about the P4 mailing list