[P4] Meres
Péter Vörös
vopraai at caesar.elte.hu
Mon Dec 14 15:37:16 CET 2015
Kimertem, a DPDK l2fwd 10Gb/s et tudja.
Nem a p4 mar nem broadcastol.
Egy picit atalakitottam a modify_field_to_const reszt, most mar ott
sincs performance vesztes ezzel 2.5Gb/s korul vagyunk
Tovabb nyomoztam mi lassit meg minket:
40.62% example_dpdk1 [.] apply_table_smac
13.13% example_dpdk1 [.] packet_received
Az apply_table_smac-ben:
│ void apply_table_smac(packet_descriptor_t* pd,
lookup_table_t** tables);// sugar at 15
│ void apply_table_dmac(packet_descriptor_t* pd,
lookup_table_t** tables);// sugar at 15
│
│ void table_smac_key(packet_descriptor_t* pd, uint8_t*
key) {// sugar at 24
│ memcpy(key, extract_bytebuf(pd,
field_desc(field_instance_ethernet_srcAddr)), 6);// sugar at 32
0.31 │ movl $0x1,0x20(%rsp)
0.04 │ movl $0x0,0x24(%rsp)
0.06 │ mov 0x20(%rsp),%rax
****
**** 74.77 │ movl $0x30,0x28(%rsp)*****
****
0.00 │ movl $0x6,0x2c(%rsp)
│ movl $0x0,0x30(%rsp)
│ mov %rax,(%rsp)
0.35 │ mov 0x28(%rsp),%rax
4.99 │ movl $0x6,0x34(%rsp)
│ movl $0x0,0x38(%rsp)
│ movl $0x0,0x18(%rsp)
│ mov %rax,0x8(%rsp)
0.34 │ mov 0x30(%rsp),%rax
4.72 │ mov %rax,0x10(%rsp)
0.30 │ → callq extract_bytebuf
│ void apply_table_smac(packet_descriptor_t* pd,
lookup_table_t** tables)// sugar at 42
Szerintem a field_desc makro a ludas. A packet_recieved fuggvenyben is
annak a kornyeken lathato a komoly lassulas.
Peti
Sandor Laki <lakis at elte.hu> írta (2015. december 14. 15:29):
> 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
>
> _______________________________________________
> P4 mailing list
> P4 at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/p4
More information about the P4
mailing list