[P4] Meres
Dániel Horpácsi
daniel-h at elte.hu
Tue Dec 15 23:32:48 CET 2015
Szia!
Remélhetőleg a [221] orvosolja a lent említett problémát. Ezek olyan
helyek maradtak, ahol nem makróval, hanem backend hívással olvastuk ki a
csomagból a mezőt; mindenesetre most már ezekben az esetekben is
helyben, fordítási időben kerülnek lekérdezésre a mezőre vonatkozó
információk (illetve a main_loop kódjában beégettem, itt majd át kell
gondolni, hogy okozhat-e problémát).
Üdv,
Dani
On 2015-12-15 10:40, Péter Vörös wrote:
> Sziasztok,
>
> Feltettem Dani patch-ét, de sajnos ettől nem lettünk gyorsabbak.
>
> Mátéval beszéltük hogy nézzem meg az l2fwd esetében mit mutat a perf:
> 45.99% l2fwd [.] _recv_raw_pkts_vec
> 37.23% l2fwd [.] l2fwd_main_loop
> 12.52% l2fwd [.] ixgbe_xmit_pkts_vec
> 1.76% l2fwd [.] l2fwd_send_burst
> 1.35% libc-2.19.so [.] __memcpy_sse2_unaligned
> 1.00% l2fwd [.] ixgbe_recv_pkts_vec
>
> Nalunk ez kb igy nez ki:
> 43.94% example_dpdk1 [.] apply_table_smac
> 14.03% example_dpdk1 [.] packet_received
> 9.77% example_dpdk1 [.] rx_recv_pkts
> 6.36% example_dpdk1 [.] rte_hash_lookup
> 5.77% example_dpdk1 [.] ixgbe_xmit_pkts_vec
> 5.23% example_dpdk1 [.] extract_intvalue
>
> Mind az apply table-ben, mind a packet_recieved-ben a field_desc-nel
> van a problema meg mindig.
> Nem nagyon értek a macrókhoz, de a field_desc az nem hoz létre egy új
> struktúrát, nem azért lassú ez az egész?
>
>
> --------------packet_recieved---------------
> │ int inport = extract_intvalue(pd,
> field_desc(field_instance_standard_metadata_ingress_port));
> │ mov 0x80(%rsp),%rax
> 16.45 │ movl $0x9,0x88(%rsp)
> │ movl $0x2,0x8c(%rsp)
> │ movl $0x0,0x90(%rsp)
> │ mov %rax,(%rsp)
> 1.06 │ mov 0x88(%rsp),%rax
> 15.96 │ movl $0x0,0x94(%rsp)
> │ movl $0x1ff,0x98(%rsp)
> │ movl $0x1ff,0x18(%rsp)
> │ mov %rax,0x8(%rsp)
> 1.17 │ mov 0x90(%rsp),%rax
> 14.26 │ mov %rax,0x10(%rsp)
> 0.88 │ → callq extract_intvalue
>
>
>
> --------------apply table---------------
>
> │ 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.30 │ movl $0x1,0x20(%rsp)
> 0.03 │ movl $0x0,0x24(%rsp)
> 0.07 │ mov 0x20(%rsp),%rax
> 75.43 │ movl $0x30,0x28(%rsp)
> │ movl $0x6,0x2c(%rsp)
> │ movl $0x0,0x30(%rsp)
> │ mov %rax,(%rsp)
> 0.34 │ mov 0x28(%rsp),%rax
> 5.12 │ movl $0x6,0x34(%rsp)
> │ movl $0x0,0x38(%rsp)
> │ movl $0x0,0x18(%rsp)
> │ mov %rax,0x8(%rsp)
> 0.38 │ mov 0x30(%rsp),%rax
> 4.62 │ mov %rax,0x10(%rsp)
> 0.33 │ → callq extract_bytebuf
>
> Dániel Horpácsi <daniel-h at elte.hu> írta (2015. december 14. 18:52):
>> Szia!
>>
>> Jó látni, milyen intenzitással lendültél a munkába :) Egy pillanattal
>> ezelőtt feltöltöttem egy olyan módosítást, ami a modify_field primitív
>> akciót már makróhívásokra fordítja, tehát nincs többé a függvényhívás
>> költsége és remélhetőleg a field_desc törzse sem marad a tárgykódban.
>>
>> Üdv,
>> Dani
>>
>>
>> On 2015-12-14 14:37, Péter Vörös wrote:
>>> 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
>>> _______________________________________________
>>> 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